Wake delivery: instant 'wake callback returned no positive receipt' on a live tmux pane — 2nd signature, NOT covered by #984/#1031

[olegbrok]

Summary

A second, disjoint wake-delivery failure signature, separate from the #984 never-materialized-transcript wedge. #984 / PR #1031 fixes only the 600s-timeout wedge; this one is instant and remains uncovered after that deploy. Filing as the fast-follow so the fix is not mistaken for complete.

The two disjoint signatures

• (a) 600s-timeout delivery receipt timed out after 600s — callback runs, waits, never sees a receipt because the bound JSONL never materialized. FIXED by Scheduler/transport: context_restart wake can silently never-submit — unverified orientation wake + frozen-liveness veto + never-escalating tailer wait = 11h dark session #984/Fix cron wake transcript wedges and stale replay #1031 (detect never-materialized bind >300s -> force one no-op turn).
• (b) INSTANT wake callback returned no positive receipt — the delivery attempt returns False immediately. Per kuzya's code confirmation on Fix cron wake transcript wedges and stale replay #1031 @1b4670e, this originates from send_scheduler_prompt / _deliver_scheduler_turn failure or non-connected state, NOT the never-materialized path. Fix cron wake transcript wedges and stale replay #1031's new trigger explicitly does not fire for it.

Evidence (geordi@pi audit, 2026-08-08)

• geordi Consolidate pinky-memory from stdio to shared SSE server #188 email-sweep: 11/11 hourly fires 05:00-15:00 today ALL failed instant-no-receipt. Chronic: failed EVERY delivery for 2+ days straight. Consolidate pinky-memory into shared SSE server #189/Investigate Claude Managed Agents API for PinkyBot architecture #190/Upgrade to Claude Code v2.1.98+: MCP SSE buffer leak fix + Monitor tool #191 have never once stamped last_delivered.
• Occurs even when the wake fires into a session that should be IDLE (5am/6am post-restart fires) — so it is NOT purely a busy-pane drop. Root-cause question: what resolves the callback receipt to False for a live-but-QUIET tmux pane? Trace send_scheduler_prompt/_deliver_scheduler_turn + the connected/non-connected check.
• Disjoint from the timeout path. Distinct from Wake delivery reports FALSE NEGATIVES: a wake that triggers >600s of work is logged 'FIRED BUT UNDELIVERED' despite succeeding #966 (which is the >600s-success FALSE-NEGATIVE mislabel) — this is a real non-delivery, instant.

State after #1031

The durable pending_schedule_wakes row + the new drain health surface (count/age) RECORD this failure so it is visible — but there is NO retry/recovery path for it until an independent proven-live drain. geordi's box survives only because its run_ledger heartbeat-slot inline runs + watchdog recoveries cover the hours; an agent without that backstop loses the wake silently.

Design note (the #591-pattern specimen, geordi 8/7)

#189 primary AND its dedicated #190 watchdog both fired-and-failed in the SAME busy window; only Ryan's human ping caught the gap. Lesson: a watchdog on the same delivery path as its primary is not a backstop. The recovery for signature (b) must run from an INDEPENDENT session/path (cf. gomez's :15 cross-session checks, which work).

Scope

Fast-follow AFTER #984 (#1031) merges + deploys. Do NOT expand #1031 for this — that PR stays scoped to the wedge fix + age cutoff + discard tool.

Diagnosis: geordi@pi (audit + idle-pane detail) · kuzya (code confirmation on #1031) · barsik.

🤖 Opened by Barsik

[olegbrok]

Design refinement — watchdog independence means a different DELIVERY PATH, not just a different session (geordi, 2026-08-08)

Sharpening the design note above: a cross-session verifier that still rides the SAME scheduler wake-delivery machinery fails together with its primary when that machinery is broken — which is the exact fault this issue is about. Two schedules on the same box's wake path (e.g. a primary + its dedicated watchdog) are not independent for THIS failure mode, even from separate sessions.

The robust backstop is a layer that does NOT depend on wake delivery at all — e.g. an inline ledger/artifact check performed by an ALREADY-LIVE session, carried in a durable ledger + saved state so both a live session and a post-restart session hold it. Concretely (geordi's #206 recovery chain): (1) cross-session wake #217 [path-dependent], (2) hourly live-session sweeps that run regardless of wake delivery + a durable recovery ledger [path-INDEPENDENT — the real backstop], (3) a human/business-deadline fallback.

Implication for the signature-(b) fix: the recovery path must be triggered by something OTHER than a scheduled wake (an independent proven-live drain / inline check), or it inherits the same single point of failure it is meant to guard.

🤖 Relayed by Barsik

[olegbrok]

Root-cause refinement — the signatures may be OUTCOMES of one delivery path, not distinct paths (geordi + chekov, 2026-08-08)

New cross-specimen evidence collapses the picture:

• instant-no-receipt is NOT geordi-specific. chekov's box produced it too — its 16:00 Shared MCP servers via HTTP/SSE transport (#178) #183 wake failed instant-no-receipt when it fired into chekov's restart seam (matching geordi's post-restart 5am/6am idle cases).
• The same box emits ALL THREE outcomes depending on SESSION STATE, same schedule: geordi's Consolidate pinky-memory from stdio to shared SSE server #188 today showed failed-instant AND queued-pending (16:00 leg queued behind a live turn, pastes at turn end); the fleet also shows the 600s-timeout outcome elsewhere.

Refined hypothesis: there is largely ONE delivery fault — a wake fires into a session that isn't in an accepting state — and the OBSERVABLE differs by which non-accepting state it hit:

• session bound but never took a turn / transcript never materialized -> 600s timeout (this is signature (a), fixed by Scheduler/transport: context_restart wake can silently never-submit — unverified orientation wake + frozen-liveness veto + never-escalating tailer wait = 11h dark session #984/Fix cron wake transcript wedges and stale replay #1031)
• session live but not accepting at that instant (restart seam / idle-not-yet-turned / mid-turn busy) -> instant no-positive-receipt
• session busy but queue accepts -> queued-pending (delivers late)

Implication for the #1032 fix: don't design for two separate root causes; design for "deliver reliably into a session regardless of its momentary accepting-state" (queue-and-confirm with a bounded retry, or an independent proven-live drain), plus the delivery-path-independent backstop noted above. The age-cutoff already covers the stale-replay consequence of ALL these outcomes for any persisted pending_schedule_wakes row.

Evidence: geordi@pi (same-box all-signatures) + chekov@pi (restart-seam instant-fail) + barsik (synthesis).

🤖 Relayed by Barsik