Cancel the scheduled alarm when a timer stops early #13

New issue

Open

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

rosa commented

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

Owner

Blocked by: #8

What to build

Stopping a timer early should cancel the alarm that was scheduled for it. Today nothing cancels it, so every timer that is stopped before it runs out leaves a transient systemd unit behind that still fires at the original end time.

Start a 25-minute Pomodoro, stop it after five, and a tomate timer check still runs twenty minutes later against whatever state exists by then. Because a check only acts on a timer that has actually run out, the usual outcome is a harmless no-op — but the units accumulate for as long as the user keeps starting and stopping timers, and a stale check acting on an unrelated later timer is a shape worth closing off rather than reasoning about each time.

Cancellation belongs next to scheduling, which #8 puts in one place.

Acceptance criteria

Stopping a Pomodoro, a short break, or a long break before it runs out cancels the alarm scheduled for it
Letting a timer run to completion leaves no unit behind either
A cancellation that fails is reported rather than swallowed, and does not prevent the timer from stopping
Starting and stopping timers repeatedly leaves no growing set of transient units
Cancelling when there is no scheduled alarm to cancel succeeds quietly

Blocked by

#8 — cancellation needs the scheduled unit to be identifiable, which means it belongs beside the single scheduling path that ticket creates

Blocked by: #8 ## What to build Stopping a timer early should cancel the alarm that was scheduled for it. Today nothing cancels it, so every timer that is stopped before it runs out leaves a transient systemd unit behind that still fires at the original end time. Start a 25-minute Pomodoro, stop it after five, and a `tomate timer check` still runs twenty minutes later against whatever state exists by then. Because a check only acts on a timer that has actually run out, the usual outcome is a harmless no-op — but the units accumulate for as long as the user keeps starting and stopping timers, and a stale check acting on an unrelated later timer is a shape worth closing off rather than reasoning about each time. Cancellation belongs next to scheduling, which #8 puts in one place. ## Acceptance criteria - [ ] Stopping a Pomodoro, a short break, or a long break before it runs out cancels the alarm scheduled for it - [ ] Letting a timer run to completion leaves no unit behind either - [ ] A cancellation that fails is reported rather than swallowed, and does not prevent the timer from stopping - [ ] Starting and stopping timers repeatedly leaves no growing set of transient units - [ ] Cancelling when there is no scheduled alarm to cancel succeeds quietly ## Blocked by - #8 — cancellation needs the scheduled unit to be identifiable, which means it belongs beside the single scheduling path that ticket creates

rosa added the

workflow

ready-for-agent

label

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