From 45f97167fdc1bcb66c73169c5d361fead49f0dbd Mon Sep 17 00:00:00 2001 From: dave Date: Fri, 3 Apr 2026 12:31:55 +0000 Subject: [PATCH] storkit: create 465_bug_timer_tick_loop_never_fires_due_entries --- ...timer_tick_loop_never_fires_due_entries.md | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 .storkit/work/1_backlog/465_bug_timer_tick_loop_never_fires_due_entries.md diff --git a/.storkit/work/1_backlog/465_bug_timer_tick_loop_never_fires_due_entries.md b/.storkit/work/1_backlog/465_bug_timer_tick_loop_never_fires_due_entries.md new file mode 100644 index 00000000..f85da967 --- /dev/null +++ b/.storkit/work/1_backlog/465_bug_timer_tick_loop_never_fires_due_entries.md @@ -0,0 +1,35 @@ +--- +name: "Timer tick loop never fires due entries" +--- + +# Bug 465: Timer tick loop never fires due entries + +## Description + +The timer tick loop (`spawn_timer_tick_loop`) is spawned by the Matrix bot runner, the Matrix bot is confirmed running (processing messages), but timers never fire. Past-due entries remain in `.storkit/timers.json` indefinitely — `take_due` never consumes them. + +The tick loop uses `tokio::spawn` which swallows panics silently. If `move_story_to_current` or `start_agent` panics on the first tick (when all past-due entries fire at once), the entire task dies with no log output. The PTY debug spam may also push any `[timer]` log entries out of the ring buffer. + +The bot command successfully adds entries to the in-memory store and persists them to disk, but the tick loop never processes them. + +## How to Reproduce + +1. Set a timer via bot command: `timer 463 HH:MM` (a time in the near future) +2. Wait past the scheduled time +3. Check `.storkit/timers.json` — entries are still present +4. Check server logs for `[timer]` — no entries found + +## Actual Result + +Timer entries remain in timers.json indefinitely. No `[timer] Timer fired` log entries appear. The story is never moved to current and no agent is started. + +## Expected Result + +Within 30 seconds of the scheduled time, the tick loop should call `take_due`, remove the entry from disk, move the story to current (if in backlog), and start an agent. + +## Acceptance Criteria + +- [ ] Add panic-catching (catch_unwind or tokio CancellationToken) to the tick loop so failures are logged +- [ ] Add a startup log line confirming the tick loop is running and how many pending timers were loaded +- [ ] Verify take_due runs on each 30-second tick by adding periodic debug logging +- [ ] Integration test: create a past-due timer entry, run the tick loop, assert the entry is consumed