msg send to a nonexistent session queues silently; target_gone escalation arrives ~24h late

[dotdevdotdev]

Goal

Three related holes in the gone-recipient lifecycle of polite messaging, found via a real loss: agentwire-dev-investigate-640 sent a load-bearing done to agentwire-dev (a session that no longer existed — likely a stale recorded parent; the live orchestrator was agentwire). It sat queued from 2026-07-03 07:52 to 2026-07-04 08:01 before dead-lettering with reason target_gone and emailing the owner.

Problems

1. No send-time existence signal. inbox.enqueue / cmd_msg_send (agentwire/msg_cli.py) only report "no recipients" for @all. Sending to a named session that doesn't exist queues silently — the sender gets a normal "Queued" confirmation and never learns the target is gone.
2. target_gone burns at the designed rate but took ~24h, not ~40 min. MAX_ATTEMPTS=40 at the ≤60s watchdog cadence should dead-letter in ~40 min; the observed gap was 24h. Investigate why attempts accrued so slowly for a gone target (sweep skipping gone sessions? drain not visiting them every tick?).
3. A gone target can't un-go by itself, yet we retry 40×. Consider a much faster escalation path for target_gone (recipient can be recreated, so some grace is fine — e.g. a handful of ticks / a few minutes), and/or re-routing report-backs whose recorded parent is gone to a live orchestrator on the same project.

Fix (minimum)

• msg send to a named nonexistent session: warn in the confirmation ("target does not currently exist — will dead-letter in ~N min unless it appears") in both text and JSON/MCP output.
• Root-cause and fix the 24h-vs-40min latency for target_gone.
• Decide + implement the fast-escalation grace window for target_gone (document the chosen semantics in docs/wiki/sessions/messaging.md).

Verification

Send a done to a made-up session name: sender sees the warning; dead-letter + owner email arrive within the documented window, not a day later.

Found during the 2026-07-04 messaging stress test.

Built by dotdev.dev

[dotdevdotdev]

Breadcrumb — fix drafted in PR #699 (worktree fix-693-694).

Root cause of the ~24h latency (problem 2): flush_session never checked target existence. Capturing a gone session returns "" → input_box_content_sgr → None → reason target_busy, which is a no-penalty defer — so attempts barely accrued. The target_gone check lived only in safe_deliver, downstream of a box gate a gone session can't pass (it was reached only on flukes, e.g. tmux target prefix-matching a live agentwire-dev-* session whose box happened to be empty — hence ~40 penalties spread over ~24h instead of 40 consecutive ticks).

Fixes shipped:

1. Send-time signal: msg send to a named nonexistent session warns in text (Warning: line), JSON (missing + warnings), and MCP msg_send output — still queues, since the target may be about to be created.
2. Drain checks the live tmux session list before the box gate; gone targets defer as penalized target_gone.
3. Fast window: GONE_MAX_ATTEMPTS = 5 (≈5 min at the ≤60s cadence), tracked in a new per-message gone_attempts counter so busy penalties accrued while the target lived don't erode the grace. Semantics locked in docs/wiki/sessions/messaging.md: only positive knowledge fast-kills — tmux unreachable (live_sessions() → None, e.g. mid-reboot) is an outage, not a gone recipient, and keeps the old no-penalty defer so queued report-backs survive restarts. Remote name@machine recipients (undeliverable by the local drain anyway) now surface as target_gone in minutes instead of pending silently forever.

Not done (explicitly out of minimum scope): re-routing report-backs whose recorded parent is gone to a live orchestrator on the same project — worth its own issue if wanted.

Tests: TestTargetGone (penalizes where old path gave no-penalty target_busy; dead-letters at exactly the gone cap; grace not eroded by prior busy attempts; reappeared target delivers; owner email on gone dead-letter) + TestSendGoneWarning (text/JSON/live/@all/unreachable-tmux). Full suite 2474 passed. Live dead-letter-within-minutes verification needs a rebuild (watchdog runs the installed tool), so it's a post-merge check.

Built by dotdev.dev