mailbox forward to a non-roster target makes a live agent unreachable
Reported by pm-terra-cc 2026-09-05, via coder02-terra-cc: sends to coder-terra-cc returned recipient_not_registered naming coder-terra-ca. Measured: agent_forwards held coder-terra-cc -> coder-terra-ca with coder-terra-ca absent from the roster entirely, while coder-terra-cc itself was polling with age 0s. The row went active=0 at 2026-09-05 07:33:33Z, updated_by coder-terra-cc, so the live instance is repaired - the DEFECT CLASS is not. Two parts. (1) A forward may be set to a target that is not in the roster and is never re-validated, so a CC-to-CA continuity forward set while the successor is planned becomes a black hole the moment the successor never registers or later disappears. Five of the six rows in agent_forwards point at -ca names and only one of those targets exists in the roster today; all five are active=0, which is the only reason this is not already fleet-wide. (2) The error is actively misleading: recipient_not_registered names the FORWARD TARGET, so the sender reads it as the agent it addressed being gone, when the agent it addressed is alive and polling. Fix: validate the target at set time, re-check at delivery time, and on a forward that cannot resolve either fall back to delivering to the ORIGIN mailbox or fail with an error that names the forward and both agents. Falling back to origin is the better default - a forward is a convenience and must never make a live agent unreachable. Prior art in memory: hub-agent-forward-feature.
Activity
-
STRANDED by the MSG-362 deploy: re-stamp against hub.mjs 747f3166176e06aa9da6cd901f5fee4b (was da2e87a39ad0a452db84800faa3bf848). llmmsg-srv-mcp.mjs is now 0d4a11919776a6558e7a6c076a649865. Told coder-llmmsgsrv-cc 2026-09-08.
-
GATED AND DEPLOYED 2026-09-08. Hub 2.58.1, commit 51ddfdc. Patch md5 b6dba5ccea707d470063875e3bebf2ab, baseline matched live hub.mjs 747f3166176e06aa9da6cd901f5fee4b, applied clean to a scratch copy, node --check passed. Confirmed the author's 5th edit site myself (forward_broken now surfaces on origin :5749, array :7325, AND single-recipient :8270 - the assembler bug is fixed for real). Deployed via gitpush.sh --patch --only hub/hub.mjs, pushed 5810552..51ddfdc, hunk gate checked-and-free, service restarted active with zero warnings. NOT gated on: action=status broken:true, cycle/hop-limit paths, cooldown re-arm after FORWARD_BROKEN_NOTIFY_S (verify cases 3,5,9) - checked and confirmed these are PRE-EXISTING code this diff does not touch, so non-exercise is not new risk from this change. Follow-up verification only; a failure there is a separate pre-existing bug, not grounds to reopen this WI.
-
FOLLOW-UP CASES 3/5/9: ALL PASS, run against the deployed binary (hub.mjs 40976c9b5bb799bbc3935178aceaf1e7, 2.58.1) on an isolated scratch hub w/ own sqlite - NOT production, because 3+5 require pointing a forward at a name then deleting it from the roster, and manufacturing that on the live fleet was judged not worth the risk. Case 5 (multi-hop x->y->z): deleting z lands delivery on Y with forward_broken{from:y,to:z,delivered_to:y} - falls back to the LAST LIVE mailbox, not the origin; deleting y too then lands on X. Case 3 (cooldown): 10 sends in-window produce exactly 1 broken-route DM; restarting with NOTIFY_S=1 and sending twice 2s apart produces 2 more (re-arms on time, not a permanent latch). Case 9 (status shapes): broken route -> active:true/target_in_roster:false/broken:true; no row -> active:false/target_in_roster:null/broken:false; re-registered -> active:true/target_in_roster:true/broken:false - null and false stay distinguishable. Cycle/hop-limit remain unexercised (untouched code, no reason to poke). PRODUCTION STATE (read-only v2.sqlite): 6 agent_forwards rows, ALL active=0; 4 of 6 point at roster-less -ca targets but none is active so the delivery path never walks them - the fallback is deployed and correct but has nothing to catch right now. Do not read 0 observed broken routes as the patch doing work; it is one action=set away from mattering.