[Bug] Desktop 3.14.0: queued automation-fire inputs are not promoted when a run ends — message stays stuck in queue on an idle session

[Bug] Desktop 3.14.0: queued automation-fire inputs are not promoted when a run ends — message stays stuck in queue on an idle session

Filed: 2026-09-19, zai-org/feedback (brunobarrientos)
App: ZCode Desktop 3.14.0 (3.14.0.7681), macOS 15.x arm64 (darwin 25.5.0), zcodeInteractionBehavior: "queue"

Summary

With a cron automation attached to a session, a fire that arrives while a turn is active is
correctly queued (session_input.delivery='queue', status='admitted'). When the active turn
completes, the queue head is sometimes promoted automatically (worked twice earlier the same
hour). In other cases promotion is silently skipped — across two consecutive turn completions —
leaving the queued message visibly parked on an idle session with only a "Steer" button, while a
newer fire of the same automation bypasses it via startNow. The skipped tick's work is lost
until a later fire; the stale item eventually flips to discarded (coinciding with a later tick)
or sits indefinitely.

Evidence (2026-09-19, Europe/Paris; source: ~/.zcode/cli/db/db.sqlite → session_input,

~/.zcode/v2/logs/2026-09-19.log)

Case 1 — 15-min finance loop, session sess_fd7c9a67… (cleanest proof)

Case 2 — 25-min extension loop, session sess_dddb86dc…

• Fire 12:42:11 → admitted; never promoted; discarded at 13:07:02, two seconds before the 13:07
  fire was promoted startNow.
• Fire 13:32:04 → admitted, still admitted at 13:59 despite turn activity ending ~13:46 and a new
  turn (turn_2b575d36) starting ~13:54.
• Fire 13:57:06 → also admitted — two pending items now queued behind active runs; the 13:32
  tick has lost ≥25 min of cadence.

Case 3 — same leak class, never cleaned

Two subagent-session inputs from Aug 30/31 are still status='admitted' three weeks later:
pending_turn_4df937cf…_1 (delivery guide), pending_turn_c9dd1565…_1 (delivery queue).

Expected

On turn completion (outcome: completed), the oldest admitted queue input for the session is
promoted automatically — the behavior observed at 11:22:07, 11:54:33 and 11:25:32.

Actual

Promotion is non-deterministic: same session, same hour — promoted twice (11:22, 11:54), skipped
twice back-to-back (12:05, 12:18). A newer fire is delivered startNow while the older admitted
item is left pending, so ticks can be skipped silently; nothing in the UI explains why the queued
message was not sent, and the item is not surfaced as superseded/stale.

Requested

1. Make flush-on-turn-end deterministic (or document the intended supersession rule).
2. If a newer fire supersedes an older admitted fire, discard it immediately and surface that in
   the queue UI (e.g. "superseded — skipped"), instead of leaving it admitted and silent.
3. Sweep stale admitted inputs (see Case 3).

Start with ~/.zcode/cli/db/db.sqlite, especially the session_input records, and compare the successful and skipped turn-ended events in ~/.zcode/v2/logs/2026-09-19.log. Trace the queue state across turn completion and later automation fires. Done means admitted inputs are deterministically promoted or clearly marked as superseded, with stale cases handled and surfaced in the queue UI.