Surface timer-scheduling failures instead of hiding or panicking #11

New issue

Open

opened 2026-08-17 19:32:00 +00:00 by rosa · 0 comments

rosa commented

2026-08-17 19:32:00 +00:00

Owner

Blocked by: #8, #7

What to build

Starting a timer should either schedule a working alarm or say it could not. Today a Pomodoro can be started with no alarm behind it and no sign anything went wrong.

The scheduler's exit status is never checked. Its stderr goes to a log line at info level, which #7 shows is invisible at default verbosity — so on a machine without a user systemd session, or with systemd-run missing, tomate pom start prints the new Pomodoro and exits 0 while nothing will ever fire. The state file is already written and the start hook has already run by that point, so the failure is silent and the timer is dead. The break paths dump stderr straight to stderr instead, which is louder but still ignores the exit status.

The same call also unwraps the path to the running executable as UTF-8 and panics if it is not.

Acceptance criteria

A scheduler that exits nonzero causes the start command to report the failure, including the scheduler's own stderr, rather than exiting 0
A missing or non-executable scheduler is reported the same way
The report tells the user the timer state was saved but no alarm was scheduled, so they know what actually happened
An executable path that is not valid UTF-8 produces an error, not a panic
Pomodoros, short breaks, and long breaks all behave identically here
Whether a scheduling failure should leave the timer running or roll it back is decided and the choice is stated in the code

Blocked by

#8 — the three copies of the scheduling call collapse into one first, so this is fixed once rather than three times
#7 — the fix moves this reporting off the invisible log path, which needs the verbosity wiring settled

Blocked by: #8, #7 ## What to build Starting a timer should either schedule a working alarm or say it could not. Today a Pomodoro can be started with no alarm behind it and no sign anything went wrong. The scheduler's exit status is never checked. Its stderr goes to a log line at info level, which #7 shows is invisible at default verbosity — so on a machine without a user systemd session, or with `systemd-run` missing, `tomate pom start` prints the new Pomodoro and exits 0 while nothing will ever fire. The state file is already written and the start hook has already run by that point, so the failure is silent and the timer is dead. The break paths dump stderr straight to stderr instead, which is louder but still ignores the exit status. The same call also unwraps the path to the running executable as UTF-8 and panics if it is not. ## Acceptance criteria - [ ] A scheduler that exits nonzero causes the start command to report the failure, including the scheduler's own stderr, rather than exiting 0 - [ ] A missing or non-executable scheduler is reported the same way - [ ] The report tells the user the timer state was saved but no alarm was scheduled, so they know what actually happened - [ ] An executable path that is not valid UTF-8 produces an error, not a panic - [ ] Pomodoros, short breaks, and long breaks all behave identically here - [ ] Whether a scheduling failure should leave the timer running or roll it back is decided and the choice is stated in the code ## Blocked by - #8 — the three copies of the scheduling call collapse into one first, so this is fixed once rather than three times - #7 — the fix moves this reporting off the invisible log path, which needs the verbosity wiring settled

rosa added the

workflow

ready-for-agent

label

2026-08-17 19:32:08 +00:00

rosa referenced this issue from a commit

2026-08-17 22:00:18 +00:00

refactor: Collapse the three timer-scheduling copies into one