Repository navigation
[Hackathon] fix(schedule): update --cron "" bypasses the empty-cron guard enforced by create #363
Description
Verified against (commit SHA or released version)
Discord Username / User ID
sheep_yd
What does this improvement do?
Summary
schedule create rejects an empty --cron with --cron is required and must not be empty, but schedule update --cron "" has no such check — it prints the frequency advisory and PATCHes cron: "" to the API.
What happened
runCreate(src/commands/schedule.ts) validates up front:opts.cron === undefined || opts.cron.trim().length === 0→localValidationError.runUpdatebuilds the PATCH body with...(opts.cron !== undefined ? { cron: opts.cron } : {})and never checks for an empty string, so--cron ""sails through to the server instead of failing fast locally.
Expected
schedule update should apply the same empty-cron validation as create.
Suggested fix
Reuse the same guard in runUpdate before building the request body, plus a unit test mirroring the create-side case. Happy to pick this up.
Details / implementation notes
No response
Confirmations
- I have searched existing issues and this is not a duplicate.
- I have provided my Discord identity above for reward coordination.
Activity
x15967311210-crypto commentedon Oct 11, 2026
PR #371 is up for this one: it gives
schedule updatethe same trim-and-reject-blank contractschedule createalready enforces for--cron, with tests on both verbs (verified non-vacuous against the previousschedule.ts).Linking it here so it can be triaged. Getting this
acceptedwould let it be claimed and the PR gate pass. Thanks!sheepyd commentedon Oct 11, 2026
Thanks for the interest, @x15967311210-crypto!
Just for maintainer context: I'm the reporter of this issue, and as noted in the description ("Happy to pick this up"), I've been planning to submit the fix myself once it's triaged, following the issue-first flow in CONTRIBUTING.md. Since the Season 4 CLI window opens on Oct 16, I was holding off rather than opening a PR before the issue is accepted.
@TestSprite maintainers — when this gets triaged, could the reporter be considered for the assignment? I'll claim it right after acceptance and have a fix with tests (mirroring the
schedule createempty-cron case) ready to open immediately. Of course, happy to go with whatever the maintainers decide.