Version: v0.5.0 (c24f605)
Steps to reproduce
- At, say, 15:00, open the schedule popover from the split send button.
- Pick today's date and 14:00, a time that has already passed.
- Leave Recurring unchecked.
- Toggle an agent and press Schedule.
What happens
The request is accepted. The countdown in the schedule strip renders blank, because there is no future moment left to count down to. The message is then sent on the next pass of the schedule runner, which app.py runs every 30 seconds.
What I expected
The request to be refused, with a reason, because the time has already gone.
Impact
The realistic way to reach this is a small mistake: 14:00 instead of 16:00, or am where you meant pm. Rather than an error you can correct, you get an immediate unintended send to whichever agents were toggled. On an agent channel that means waking those agents straight away, so a mistyped hour turns into real work starting.
The value also reaches ScheduleStore.create() unchecked, so a non-finite or absurd timestamp can be written into data/schedules.json the same way.
Suggested direction
Validate in the store rather than only in the UI, so every caller is covered, and have POST /api/schedules translate the rejection into a 400 carrying the reason instead of a 500 error page. The popover can then stay open and show what was wrong.
Fixed by #95, which refuses a send time that is in the past, non-finite, or beyond the year 2100, and adds tests for each guard.
Version: v0.5.0 (
c24f605)Steps to reproduce
What happens
The request is accepted. The countdown in the schedule strip renders blank, because there is no future moment left to count down to. The message is then sent on the next pass of the schedule runner, which
app.pyruns every 30 seconds.What I expected
The request to be refused, with a reason, because the time has already gone.
Impact
The realistic way to reach this is a small mistake: 14:00 instead of 16:00, or am where you meant pm. Rather than an error you can correct, you get an immediate unintended send to whichever agents were toggled. On an agent channel that means waking those agents straight away, so a mistyped hour turns into real work starting.
The value also reaches
ScheduleStore.create()unchecked, so a non-finite or absurd timestamp can be written intodata/schedules.jsonthe same way.Suggested direction
Validate in the store rather than only in the UI, so every caller is covered, and have
POST /api/schedulestranslate the rejection into a 400 carrying the reason instead of a 500 error page. The popover can then stay open and show what was wrong.Fixed by #95, which refuses a send time that is in the past, non-finite, or beyond the year 2100, and adds tests for each guard.