4283 Commits

Author	SHA1	Message	Date
Ben Barclay	866332bfb5	fix(relay): authorize send_message targets and surface egress declines (P5) (#99220) ... * fix(relay): authorize send_message targets and surface egress declines P5 of the relay egress-authorization workstream. The relay path authenticated the SENDER but never authorized the DESTINATION, and the gateway compounded it from both ends. (a) send_message could silently name an arbitrary relay target. Its `target` parameter is free-form ('platform:chat_id'), so a model could name ANY chat id and the gateway would emit an outbound frame for it. gateway/relay/egress.py adds an attestation floor: a relay-routed destination must have a provenance this gateway can show -- the operator's home channel, the channel directory, or its own gateway session origins. Anything else is refused HERE, with a visible tool error naming the target, before a frame is written. Non-relay platforms and platforms served by a live native adapter in this process are untouched (same precedence resolve_delivery_transport applies). (b) Connector declines were swallowed into apparent successes. The connector's egress floor answers an unauthorized destination with a DEFINITE failure whose text is deliberately uniform (F-005). Several relay lanes degrade a *transport drop* by design and were degrading an *authorization refusal* the same way: - _send_media returned None, sending the caller into BasePlatformAdapter's text fallback -- a DIFFERENT op re-addressed at the very chat the connector had just refused. - _send_prompt returned None, so exec-approval / slash-confirm / clarify reported "relay prompt op unavailable" (a wrong reason) and ran their numbered-text fallbacks into the refused chat. - task_card_stop discarded the error entirely. - typing / delete / react / thread ops degraded silently at debug. is_egress_decline() classifies THAT a decline happened (never why -- the uniform text is not parsed for reasons) and requires a definite, non-ambiguous failure, so a lost-ack retry is still a transport outcome. Lanes with an error-carrying contract now report the decline verbatim; cosmetic bool/None lanes still degrade but log it at WARNING. Advisory progress drops that legitimately degrade are unchanged: the task_card send lane, the draft ambiguous/except branches, and every transport-exception path keep their existing fail-open behaviour. Tests: 21 mutations of the production source, all KILLED. * fix(relay): authorize the RESOLVED target; declines must not fall back Review round 1 (independently confirmed by a second reviewer) found three blockers. Two are fixed here; the third (B-2, Telegram @username) is a policy decision left open deliberately. B-1 — THE FIX CAUSED THE OUTAGE IT PREVENTED (tools/send_message_tool.py) The P5(a) guard ran ABOVE Slack user->DM resolution, so it authorized the internal pseudo-id `_parse_target_ref` emits (`user_name:ben`, `user:U...`). Provenances only ever hold RESOLVED conversation ids, so a fully attested DM was compared as a handle against a set of `D...` ids and refused: base slack:@ben SENT head(before) slack:@ben REFUSED Every Slack DM by handle was broken. Moved the guard below resolution; it now authorizes the destination that is actually sent to, and the refusal names the resolved id. Position is load-bearing, so it is commented as such and pinned: reverting the move turns exactly the four new cases red. B-3 — A DECLINE IS NOT A LANE FAILURE (gateway/run.py) `_approval_send_outcome` had only sent/failed/ambiguous, so a connector decline collapsed into `failed` — which is the cue to run the plain-text fallback into the chat the connector had just refused. The adapter fix in the previous commit improved the error STRING while user-visible behaviour stayed identical to base; the commit message overstated it. Fixed properly: - new `declined` verdict, recognised via the shared `is_egress_decline` contract (not string sniffing at the call site) - exec-approval returns without the text fallback - slash-confirm suppresses the text reply AND clears the registration, so a card that never rendered cannot capture the user's next message `send_clarify` was already correct (returns early inside the adapter). MUTATIONS (production source; both directions) classifier never returns 'declined' -> KILLED (4 cases) ALL failures classified as 'declined' -> KILLED (2 cases) guard moved back above Slack resolution -> KILLED (4 cases) decline CODE changed (review M05) -> KILLED marker match made case-sensitive (M10) -> KILLED M05 was a tautology: the test asserted the imported constant against itself, so changing the constant could not fail it. The wire contract is now pinned as a literal, because the connector stamps that exact string and a one-sided change is a silent cross-repo break. REGRESSION CHECK: the 12 failures + 1 collection error in this test selection are PRE-EXISTING cross-test contamination — the identical set fails at 7cf86188ac. Verified by diffing the failing sets: no new failures, 363 -> 374 passed. NOT FIXED (deliberate): B-2, Telegram `@username`. The Bot API resolves handles at send time, so there is no id to compare and no canonicalization exists yet. That is a policy decision, not a code move. * fix(relay): fail CLOSED on guard faults; classify the structured decline Third independent review. Two more blockers, both reproduced before fixing. 1. THE GUARD ITSELF FAILED OPEN (tools/send_message_tool.py:158) `_authorize_relay_target` wrapped BOTH the import and the call in one `except Exception: return None` — and None means AUTHORIZED at every call site. So any runtime bug inside the guard silently switched the entire P5(a) boundary off. Reproduced: with the guard raising, an unattested target sent. The docstring already stated the correct intent ("must not fail closed on its own IMPORT error") and the code did something broader. The two failures are not the same: a missing gateway package means there is no relay egress to authorize; a fault inside the guard means authorization did not happen. The import is tolerated, the call is not — a guard that cannot answer refuses. 2. THE STRUCTURED DECLINE WAS THROWN AWAY (gateway/run.py) The adapter preserves the connector's dict in `SendResult.raw_response`. My previous commit rebuilt a dict from the error STRING, which loses two contracts: * a decline carrying `code: egress_declined` and NO text renders as "relay egress declined" — no marker colon — so it classified as `failed`, which is exactly the cue to run the fallback into the refused chat; * `ambiguous: True` (lost ack) was flattened into a DEFINITE failure, re-sending a card that may already be on the user's screen. That is the duplicate-card bug the ambiguous verdict exists to prevent, reintroduced by the fix meant to harden the same path. Both call sites now classify `raw_response` when present, ambiguity first, and fall back to the wire sentence only for connectors that send no structured response. I had fixed the text-marker path and tested only the text-marker path. Worth naming: the review's probe was a shape my tests never produced. MUTATIONS (production source) guard fault returns None (fail open again) -> KILLED classifier ignores raw_response -> KILLED (3 cases) ambiguous treated as a definite failure -> KILLED (2 cases) 40 focused tests pass. Regression check vs be321faf27: identical 13-item failing set (pre-existing cross-test contamination), no new failures. STILL OPEN: B-2 / finding 3, Telegram `@username`. The reviewer is right that this is a REGRESSION of an existing contract (#53573 added Bot API username support), not merely an unspecified input, since relay provenance stores the numeric chat id. Fixing it means resolving the handle before authorization, or explicitly revoking the contract. That is a policy decision, not a code move, and it is Ben's call. * test(relay): pin M21 and M25, the survivors whose comments called them load-bearing Round-2 review reported six unpinned survivors from round 1. Two guard real behaviour and are now covered; the other four are cosmetic-lane warnings and fail-open branches I am leaving documented rather than pretending to close. M25 — thread-qualified session ids. `_session_ids` adds BOTH "chat:thread" and the bare chat, because the connector authorizes the CHAT. Without the split a gateway whose session origin is `-100999:77` cannot send to `-100999`, the chat it is demonstrably already talking in. KILLED. M21 — the generic `relay` plane must union every fronted platform, since a relay session is filed under its LOGICAL platform. KILLED. MY FIRST M21 TEST WAS THE DEFECT IT WAS TESTING FOR. I patched `_relay_fronted` — the very function the mutation empties — so emptying it changed nothing the test could see, and the mutation SURVIVED against a green test. Rewritten to drive the real `relay_fronted_platforms()` through its env source (`GATEWAY_RELAY_PLATFORMS`), which is how production learns it. That is the same "the test verifies my stand-in" failure I have spent this workstream removing from the connector harnesses, reproduced here in three lines of Python. The tell was identical: a mutation that survives a test written specifically to kill it. 334 tests pass. NOT PINNED, deliberately: M03 (success-guard on a malformed dict), M24 (empty-target allowance — the one fail-open branch, reachable only when the bare-platform path already resolved a home channel), M35/M36 (decline WARNINGs on cosmetic lanes). All four are observability or defence-in-depth rather than authorization, and the review agrees they are non-blocking. * fix(relay): defer Telegram @username authorization to the connector (B-2) Closes the last blocker. Two reviewers independently called this a REGRESSION of the public-channel username support added in #53573, not an unspecified input, and they were right: provenance stores RESOLVED numeric chat ids, so comparing `@channel` against them could only ever refuse. WHY THE GATEWAY CANNOT ANSWER IT. The guard fires only when there is no live native adapter — i.e. relay-fronted deployments — and on exactly those the CONNECTOR holds the bot token, not this process. There is no local way to turn a handle into the numeric id. Refusing here is not "fail closed", it is "fail always". WHY DEFERRING IS SAFE. The destination is still authorized one layer out: the connector's Telegram egress floor (gg#238, merged 743a7c2) classifies and refuses unauthorized destinations after ITS resolution — the layer that closed the reported vulnerability in the first place. Handles go from two guards to one, the authoritative one, not to zero. The carve-out is deliberately narrow and its EDGES are pinned, because the failure mode of an exemption is silent widening: telegram `@handle` -> deferred (the regression case) telegram numeric id -> still guarded matrix `@user:server` -> still guarded (telegram-only) bare name, no `@` -> still guarded attested handle -> normal path, attestation still consulted MUTATIONS carve-out widened to all platforms -> KILLED carve-out widened to every target -> KILLED carve-out removed (regression back) -> KILLED carve-out checked BEFORE attestation -> KILLED THE ORDERING MUTANT SURVIVED MY FIRST TEST. Both orderings return None, so asserting the verdict could not tell them apart — the test asserted the claim instead of the mechanism. Rewritten to observe that attestation is actually consulted. Same defect class as the M21 test earlier in this branch: a mutation surviving a test written specifically to kill it means the test is measuring the wrong thing. 341 tests pass. FOLLOW-UP (option 2, Ben's call, deliberately NOT done here): resolve the handle before authorizing so BOTH layers apply. That needs a resolution round-trip through the connector — new wire surface — so it belongs in its own phase rather than bolted onto this one. Recorded in the code comment at the carve-out, not just here. * fix(relay): close two fail-open boundaries; test the code-only decline for real Both blockers from review, each REPRODUCED before fixing. 1. STRUCTURED DECLINE HAD NO GUARD. Deleting `raw_response=result` from both `_send_prompt` return branches left all 34 tests green — a surviving, non-equivalent security mutant. The `code` field is the documented PREFERRED signal precisely because a connector may send no prose, and a caller rebuilding `{"success": False, "error": ...}` cannot see it. Cause: every existing case declines with marker TEXT. The evidence for the code-only path was a hand-built SimpleNamespace in a different file — a stand-in for the adapter, so it verified my fixture instead of production. Fixed with a CodeOnlyDecliningConnector driving the real `send_exec_approval` -> `_send_prompt`, feeding the REAL SendResult to the REAL `_approval_send_outcome`, plus the same shape on the media lane. drop raw_response SURVIVED (34 passed) -> KILLED 2. TWO FAIL-OPEN BOUNDARIES, both "absence" and "fault" sharing a return. `_relay_fronted` swallowed EVERY exception and returned an empty set, which `relay_routed_platform` reads as "not relay-routed" — skipping the guard. Probe, with a positive control in the same run: positive_control_denied = True discovery_fault_denied = False <- unattested target AUTHORIZED `_authorize_relay_target` caught every exception during IMPORT as "no gateway package". A module that exists and fails to initialize is a fault, not an absence, and returning None there means authorized. Now: ImportError alone is absence; anything else raises RelayRouteUnknown and `authorize_relay_target` converts it to a REFUSAL STRING (not a raised exception — every caller treats the return value as the verdict, so raising would trade a fail-open for a crash). Kept the converse under test so "fail closed" does not silently become "refuse everything in CLI/cron", which is the outage the broad except existed to prevent. discovery fault -> empty set KILLED RelayRouteUnknown -> authorized KILLED import fault -> authorized KILLED 397 passed (was 392, +5 new cases), zero failures. * fix(relay): close all seven review-round-3 blockers Every finding reproduced before fixing; every fix mutation-checked after. CONTENT LEAKS (the decline was laundered into a different op, same chat) #1 A declined DRAFT SEAL replayed as a plain send. On stream-is-the-message platforms the turn-final becomes draft(final=True); `_seal_open_draft` dropped the structured body, so `_absorb_into_open_draft` read a REFUSAL as a lane failure and fell through. Probe, Slack descriptor: before: draft(partial) -> draft(final,SECRET) -> send(SECRET) after: draft(partial) -> draft(final,SECRET) My first probe of this used a discord descriptor and showed no seal at all — the leak is real, my probe was wrong (streams only arm for Slack). #6 Task-card PROGRESS had the same defect one lane over: a bare failed SendResult reads as "card lane unavailable", and TurnRunner then sends the task text to the same chat. Both card methods now carry raw_response and the caller suppresses the fallback on a decline. AUTHORIZATION BYPASSES #2 `except ImportError` was NOT the fix I claimed last round. ImportError also covers a broken dependency inside an INSTALLED gateway; review probed `ImportError.name = "gateway.relay.dependency"` and got an authorized verdict. Now only a name identifying the gateway relay module itself is absence. An ImportError with NO name stays absence — refusing on a fault we cannot attribute would trade an unidentifiable bug for a real CLI/cron outage, and an existing test caught exactly that when I first got it wrong. #3 `relay_routed_platform` lowercases the requested platform; `_relay_fronted` returned configured names verbatim. A platform configured as "Discord" missed the membership test, looked native, and skipped the guard: 'discord' => refused 'Discord' => ALLOWED 'DISCORD' => ALLOWED An attestation bypass on a string comparison. UNDELIVERABLE PROMPTS THAT HUNG #4 `_clarify_send_disposition` handled `failed` and `ambiguous` but not `declined`, so a REFUSED clarify card fell through to wait_for_response and blocked until clarify_timeout — indefinitely when configured non-positive. A decline is more definitive than a failure, not less. #5 The exec-approval decline branch returned quietly, which suppressed the text fallback (right) but left the CENTRAL approval entry pending (wrong) — the dangerous command stayed blocked until the approval timeout. My comment claimed the registration was torn down; only RelayAdapter's private map was. It now raises `_ExecApprovalDeclined`, which propagates to `_await_gateway_decision`'s existing notify-failure path (drops the entry, unblocks the tool). A dedicated type, re-raised past the local `except Exception` that would otherwise have restored the leak. #7 THE GAP THAT LET ALL OF THIS SHIP. Both caller-level suppressions were unfalsifiable: deleting either branch left 36/38 tests green. The suites drove `_approval_send_outcome` and `RelayAdapter` but never the real TurnRunner / busy-session callers, so nothing observed whether a text send FOLLOWED a decline — which is the whole property. tests/gateway/test_decline_fallback_suppression.py drives both real callers and records every send. Each decline case is paired with an ordinary-FAILURE control, because without one a caller that never falls back would also pass. MUTATIONS (all on production source, anchors count-checked, restored after) #1 seal decline -> plain send KILLED #1b seal drops raw_response KILLED #2 nested ImportError -> authorized KILLED #3 fronted set not normalized KILLED #4 clarify declined branch removed KILLED #5 approval decline returns not raises KILLED #6 task_card drops raw_response KILLED #7 slash-confirm suppression removed KILLED #7's two were the reviewer's SURVIVORS (36/38 passing); both now die. 425 passed, zero failures. * fix(relay): close the three round-4 blockers Round 4 confirmed six of seven round-3 fixes and found three more. Each reproduced before fixing, each mutation-checked after. 1. A NAMELESS ImportError still authorized. Last round I admitted it as "absence" to protect the CLI/cron path. That reasoning was WRONG and the interpreter says so: import gateway.relay.nope -> ModuleNotFoundError, name="gateway.relay.nope" import totally_absent_pkg -> ModuleNotFoundError, name="totally_absent_pkg" Genuine absence is ALWAYS ModuleNotFoundError with `.name` set, so the CLI/cron path never produces a bare ImportError and nothing legitimate was being protected. A plain or nameless ImportError comes from an import hook or a module that failed while initializing — an unattributable FAULT. Now: absence is ModuleNotFoundError naming gateway / gateway.relay / gateway.relay.egress; everything else refuses. Two existing tests raised a bare ImportError to simulate absence and were corrected to the real shape. 2. SESSION ATTESTATION INVENTED IDS. `_session_ids` split every id on the first colon to recover "chat" from "chat:thread". Matrix ids contain a colon natively, so `!room:server.org` attested a bare `!room` — the guard vouching for a destination on its own fabrication. The split now applies only to platforms whose ids genuinely carry a `:thread` suffix (allow-list; unknown platforms are treated as un-splittable, which can only refuse more). Kept a Slack control: dropping the split entirely would refuse legitimate thread replies, which is the outage the split exists to prevent. 3. THE TASK-CARD FIX WAS UNFALSIFIABLE — my own round-3 mistake, and the same one round 3 caught me making. I added the production branch AND a test, but the test stopped at RelayAdapter: it proved `raw_response` is carried and never called `TurnRunner._task_card_publish`, which owns the property. Deleting the real branch left 30 tests green. Now driven through the real caller, with an ordinary-failure control. The lesson generalises: proving the DATA reaches the boundary is not proving the CALLER acts on it. Every one of these decline fixes has two halves and the second half is where the security lives. Also closed the round-4 non-blocking finding: `gateway/relay/egress.py` has its OWN import boundary, and the existing test intercepted the earlier import in tools/send_message_tool.py, so it was never exercised. Mutating that classifier to treat every ImportError as absence now dies. MUTATIONS (production source, anchors count-checked, restored after) R4-1 nameless ImportError -> authorized KILLED R4-2 session split unconditional KILLED R4-3 task-card caller branch removed KILLED (was SURVIVED) egress classifier: any ImportError = absence KILLED Also probed and found NOT a leak: a refused OPENING draft frame disarms the stream and the turn-final goes out via `send`. That send is itself guarded and the connector refuses it too, so no content is delivered — unlike the seal case (round 3, #1) where the seal was the only check on that path. 452 passed, zero failures. * fix(relay): recover the thread parent from thread_id, not a colon split Round 4 blocker 2 was closed with an allow-list of platforms whose ids have no native colon. Reviewing my own fix while round 5 ran, the allow-list is the wrong mechanism: it NARROWS a guess instead of removing it, and it still gets Matrix wrong the moment a Matrix session is thread-qualified (`!room:server.org:$thr` -> split yields `!room`). The structured field was there all along. `_session_entry_id` composes the id as f"{chat_id}:{thread_id}" and the entry still carries `thread_id` separately, so the parent is knowable EXACTLY: strip the known suffix, or add nothing. No platform list, no guessing, correct for ids that contain colons. Mutations: back to splitting on the first colon KILLED thread parent never recovered (over-refuse) KILLED Both directions matter: the first invents attestations, the second refuses legitimate thread replies. One existing test (M25) asserted the right PROPERTY with a fixture that omitted `thread_id` — a shape real entries never have. Fixture corrected, assertions untouched. 453 passed. * fix(relay): close the four round-5 blockers Each reproduced before fixing, each mutation-checked after. R5-1 A DISABLED NATIVE ADAPTER BYPASSED AUTHORIZATION. `_has_live_native_adapter` treated any entry in the adapter map as native; `resolve_delivery_transport` ignores a native adapter whose config is disabled and routes over Relay. Two independent routing classifiers, disagreeing: guard says native: True delivery routes relay: True So the guard skipped authorization for a send that went over the relay. The guard now applies the router's enabled-state rule; probed both configurations and they agree. R5-2 THREAD IDS WERE NEVER AUTHORIZED. The parser splits chat_id and thread_id; only chat_id reached the guard. On Discord the thread IS the destination — `POST /channels/{thread_id}/messages` — so an attested parent channel authorized an arbitrary caller-supplied thread. `authorize_relay_target` now takes thread_id and requires its own attestation (bare id or the `chat:thread` form a session origin produces); both call sites forward it. R5-3 A DECLINED **INITIAL** DRAFT WAS RETRIED AS A PLAIN SEND. Round 3 fixed the declined SEAL; the declined OPEN was a different path. `send_draft` returned a bare failure, so the stream consumer read "draft transport unusable", disabled drafts and fell through to `_first_send`. Measured through the real adapter and real StreamTransportMixin: before: ops ['draft', 'send'] after: ops ['draft'] send_draft now carries raw_response; a decline is terminal for the run and the guard sits in `_first_send`, where every fallback path converges. R5-4 MY ROUND-4 TASK-CARD FIX SUPPRESSED EXACTLY ONE UPDATE. It set `native_failed`, which the entry gate already uses for an ordinary broken lane, so the next progress event skipped the decline branch and went straight to the text fallback: after first publish: [] after second: ['send'] Terminal declines are now a separate `egress_declined` state checked at the entry gate. A refusal does not expire after one tick. MUTATIONS R5-1 disabled native counts as native KILLED R5-2 thread_id not authorized KILLED R5-2b tool does not forward thread_id KILLED (was SURVIVED) R5-3 initial-draft decline not terminal KILLED R5-3b _first_send guard removed KILLED R5-4 declined state not persistent KILLED R5-2b is the same gap that produced findings 3 and 4 of the last two rounds, a third time: every test called `authorize_relay_target` directly, so dropping the argument from the TOOL WRAPPER changed nothing. Testing the callee never proves the caller uses it — now pinned explicitly. Each fix ships with an ordinary-failure control, because every one of these makes the guard refuse MORE, and over-refusal is now the larger risk. 474 passed, zero failures. * refactor(relay): declare the terminal-decline state where it lives Both terminal-decline flags were set dynamically. They worked (neither class is frozen or slotted) but an undeclared attribute hides the state from anyone reading the class, and this one is security-relevant. _TaskCardState.egress_declined — declared dataclass field StreamConsumer._egress_declined — initialised in __init__ Lifetime verified while checking whether a refusal can leak ACROSS turns and mute a healthy destination: it cannot. _TaskCardState is constructed per progress-drain (run_turn_runner.py:420) and the consumer's flags per run (stream_consumer.py:163), so both are fresh each turn. Also verified the guard's blast radius after adding thread authorization: the ONLY callers of authorize_relay_target are the two model-facing send_message call sites. Gateway-internal sends — notably the handoff path, which creates a thread and immediately posts to it with no session provenance yet — go through transport.adapter directly and are unaffected. That was the most plausible over-refusal, and it does not reach this guard. 461 passed. * fix(relay): close the four round-6 blockers — the edit lane R6-1 MY OWN R5-1 FIX REINTRODUCED THE BYPASS IT CLOSED. I wrote `except Exception: return True` around the config lookup, so a config read fault declared the platform native while the ROUTER, reading the real config, sends over the relay: guard_has_live_native True guard_verdict None router relay Routing we cannot determine is UNKNOWN. It now raises RelayRouteUnknown, which the outer handler must re-raise rather than flatten to False, and `authorize_relay_target` turns into a refusal. This is the second time a convenience `except` in this function created a bypass; there is now no permissive return left in it. R6-2/3/4 THE NINTH LANE: `edit`. ONE dropped field, THREE leaks. `RelayAdapter.edit_message` discarded the connector response, and three independent callers read a bare edit failure as "editing is unavailable" and re-send the content as a NEW message to the same chat: stream edit fallback ['edit', 'edit', 'send'] the unseen tail queued reconciliation ['edit', 'send'] the WHOLE response task-card fallback ['edit', 'send'] the task text again Fixed at the source (edit_message carries raw_response) plus each caller: `_on_edit_failure` — the single funnel for stream edit failures — makes a decline terminal for the run, `_send_fallback_final` refuses to deliver a continuation after one, the queued reconciler returns instead of sending, and the task-card fallback sets the same terminal state R5-4 introduced. R5-4 fixed the native task-card op and I did not check its sibling fallback path. The pattern across rounds 3-6 is consistent: the fix goes where the decline is OBSERVED, and the leak lives wherever someone else later decides to retry. MUTATIONS R6-1 config fault -> assume native KILLED R6-1b RelayRouteUnknown swallowed as False KILLED R6-2 edit drops raw_response KILLED R6-2b edit-failure decline not terminal KILLED R6-3 queued reconcile falls back on decline KILLED R6-4 task-card fallback edit decline KILLED Each with an ordinary-failure control: a genuinely un-editable message must still be delivered, and a broken card lane must still reach the user. 481 passed, zero failures. * fix(relay): add a terminal-decline latch at the adapter choke point THE STRUCTURAL FIX, not a twelfth local check. Rounds 3-6 of review found ONE defect in eleven lanes: the connector refuses an op, and some caller downstream reads that as 'this lane is unavailable' and retries the same content through a DIFFERENT op against the SAME chat. Media, prompt, draft-open, draft-seal, native task card, task-card fallback edit, slash-confirm, exec-approval, clarify, stream edit, queued reconciliation. Each was closed by adding a check at one more call site. That approach cannot converge: gateway/ has ~60 outbound call sites, every one of them a place a future change can reintroduce this, and four consecutive review rounds each found another. The reviewer's own count of lanes is the argument against the per-site design. Every relay frame from every one of those callers passes through _transport.send_outbound. One latch there covers them all: once the connector refuses a chat, this adapter stops emitting CONTENT frames for that chat. Proven to subsume the local checks: with the stream-edit per-site check DISABLED, the leak probe still reports blocked=true — the frame never reaches the wire. The local checks stay as defence in depth and for their better error messages, but they are no longer the only thing standing between a decline and a re-addressed send. Scope is deliberately narrow, and each limit is mutation-pinned: per CHAT - a refusal must not mute other conversations CONTENT ops - typing/delete carry nothing; latching them would leave a stuck typing indicator for no security gain self-healing - cleared when the connector accepts that chat again, so a transient policy change does not need a restart Mutations: latch never set KILLED latch never consulted KILLED latch is global, not per-chat KILLED latch never clears KILLED 485 passed. * fix(relay): one route source; the latch already covered round 7's lanes Round 7 reviewed 573e41e294 — one commit BEFORE the terminal-decline latch — and independently reached the same conclusion I had: 'The per-call-site approach is structurally wrong. Use one turn-scoped choke point.' That is the latch in 6dbc004594. Its four 'still broken' lanes (tool-progress edit, progress-overflow edit, long-running heartbeat edit, stale streamed-final reconciliation) all share the shape edit_message->declined->adapter.send(same chat, same content), and NONE has a local check. Probed all four against the latch: tool_progress ops ['edit'] blocked progress_overflow ops ['edit'] blocked heartbeat ops ['edit'] blocked stale_final ops ['edit'] blocked That is the argument for the choke point, measured: lanes nobody patched are safe anyway. Pinned by a parametrized test named for those four lanes. R7-1 IS A REAL BYPASS THE LATCH DOES NOT COVER, and it is fixed here. The guard rebuilt routing from GATEWAY_RELAY_PLATFORMS while resolve_delivery_transport asks the CONNECTED adapter (fronts_platform, from the handshake identity set). Different snapshots: with env discovery stale or momentarily empty, the guard said 'native' and the router sent over the relay, skipping authorization. before: guard_relay_routed False / delivery relay after: guard_relay_routed True / delivery relay / unattested target refused The guard now asks the live adapter first and falls back to config only when there is no runner (CLI/cron) — pinned in both directions. R7-5 (non-blocking, and a fair hit): my stream-fallback test asserted _egress_declined and never drove _send_fallback_final, so removing that early return SURVIVED. The test now calls the real fallback and asserts the wire is untouched; the mutation dies. Mutations: R7-1 guard ignores the live adapter KILLED (was SURVIVED) R7-5 fallback early return removed KILLED (was SURVIVED) latch not consulted KILLED 491 passed. * fix(relay): close three holes found by attacking my own latch Round 8's brief told the reviewer to attack the latch. I did the same in parallel and found three real holes in it before the review returned. 1. send_for_platform BYPASSED THE LATCH ENTIRELY. It builds and posts its frame directly rather than through _outbound — and it is the delivery resolver's OWN entry point, so it is the single most important caller. before: ops ['edit', 'send'] after: ops ['edit'] gateway/AGENTS.md states the rule I had just broken: 'Seal-interception exists at BOTH egress doors (send() and send_for_platform()); a new egress door needs the same two checks.' The latch is a third such check and I had wired it to one door. 2. A COSMETIC SUCCESS CLEARED THE LATCH. Clearing on ANY success meant a typing indicator — routinely allowed for a chat whose content is refused — re-opened the door for the very next send: ops ['edit', 'typing', 'send'] Only a CONTENT op the connector accepted may clear it now. 3. A THREAD INSIDE A REFUSED CHAT WAS NOT COVERED. A thread lives inside its parent, so the same content reached the same conversation one level down: ops ['edit', 'send'] The latch key now strips the thread suffix. Also normalised int/str chat ids (callers pass both; a type mismatch would silently unlatch). MUTATIONS send_for_platform not latched KILLED cosmetic success clears the latch KILLED thread suffix not stripped KILLED draft-seal retry not latched SURVIVED — EQUIVALENT, proven: is unreachable while latched (a declined edit before the seal produces ZERO seal frames, measured). Kept as defence in depth because it posts directly, and documented at the site rather than covered by a test that could not fail. One self-inflicted bug on the way: a blanket replace put 1Password CLI brings 1Password to your terminal. Turn on the 1Password app integration and sign in to get started. Run 'op signin --help' to learn more. For more help, read our documentation: https://www.1password.dev/cli 1Password CLI is built using open-source software. View our credits and licenses: https://downloads.1password.com/op/credits/stable/credits.html Usage: op [command] [flags] Management Commands: account Manage your locally configured 1Password accounts connect Manage Connect server instances and tokens in your 1Password account document Perform CRUD operations on Document items in your vaults events-api Manage Events API integrations in your 1Password account group Manage the groups in your 1Password account item Perform CRUD operations on the 1Password items in your vaults plugin Manage the shell plugins you use to authenticate third-party CLIs service-account Manage service accounts user Manage users within this 1Password account vault Manage permissions and perform CRUD operations on your 1Password vaults Commands: completion Generate shell completion information inject Inject secrets into a config file read Read a secret reference run Pass secrets as environment variables to a process signin Sign in to a 1Password account signout Sign out of a 1Password account update Check for and download updates. whoami Get information about a signed-in account Global Flags: --account account Select the account to execute the command by account shorthand, sign-in address, account ID, or user ID. For a list of available accounts, run 'op account list'. Can be set as the OP_ACCOUNT environment variable. --cache Store and use cached information. Caching is enabled by default on UNIX-like systems. Caching is not available on Windows. Options: true, false. Can also be set with the OP_CACHE environment variable. (default true) --config directory Use this configuration directory. --debug Enable debug mode. Can also be enabled by setting the OP_DEBUG environment variable to true. --encoding type Use this character encoding type. Default: UTF-8. Supported: SHIFT_JIS, gbk. --format string Use this output format. Can be 'human-readable' or 'json'. Can be set as the OP_FORMAT environment variable. (default "human-readable") -h, --help Get help for op. --iso-timestamps Format timestamps according to ISO 8601 / RFC 3339. Can be set as the OP_ISO_TIMESTAMPS environment variable. --no-color Print output without color. --session token Authenticate with this session token. 1Password CLI outputs session tokens for successful 'op signin' commands when 1Password app integration is not enabled. -v, --version version for op Run 'op [command] --help' for more information on the command. into send_for_platform, which has no such variable. Two existing unfurl tests caught it — NameError at adapter.py:1407. 504 passed. * fix(relay): Telegram handle exemption + a turn boundary for the latch Round 8 blockers. Two of its four were already closed by 93750e351a (it reviewed the commit before it); these two are real and both are mine. B1 — THE TELEGRAM @HANDLE EXEMPTION COVERED A NATIVE SEND. _is_unresolved_handle exempts telegram @handles from attestation because "the connector resolves and authorizes it". That justification is FALSE whenever the gateway holds its own token: _send_to_platform calls _send_telegram(pconfig.token, ...) directly and no connector is involved. So an unattested @handle went out under the gateway's own credential while the numeric control was correctly refused. The exemption now requires that no native credential exists. A probe fault WITHDRAWS the exemption (falls back to the ordinary attestation check) rather than granting it. Shipped with the converse control: relay-only config still exempts @handles, and numeric targets stay guarded in both modes. B4 — THE LATCH HAD NO BOUNDARY, SO IT WAS AN OUTAGE MECHANISM. My own regression, and worse than reported. Removing "clear on cosmetic success" (correctly) removed the ONLY way the latch could ever clear: a content op can never reach the connector to succeed, because the latch blocks it locally first. A refusal at 09:00 muted that chat forever. A new inbound message for a chat is the generation marker — the natural teardown point. Suppression still holds for the whole turn. same_turn_blocked: true next_turn_delivered: true MUTATIONS (all killed) handle exemption ignores native credential native-credential fault GRANTS the exemption no turn boundary (latch never clears) teardown clears ALL chats not just this one teardown ignores the chat The last two SURVIVED first: I tested _clear_declined_for_turn directly and never proved _on_inbound calls it — the caller-level gap that has now produced four blockers on this branch. Added a test driving the real inbound entry point. One self-inflicted bug, caught by my own fault test: the probe imported load_config, which does not exist (it is load_gateway_config), so it always threw and returned the fault default. The test that pinned fault behaviour is what exposed it. 510 passed. * fix(relay): correct latch identity and boundary; one config snapshot Round 9, four blockers, all reproduced. B1+B4 — THE TEARDOWN WAS AT THE WRONG PLACE, twice over. It sat on the adapter's raw _on_inbound, which runs BEFORE profile routing, the ignored-channel guard, plugin hooks and user authorization. An unauthorized or dropped event could therefore clear a refusal belonging to an active turn, and stale content then went out as a different op. The same placement missed Discord interaction passthrough, which builds its own MessageEvent and calls handle_message directly, so slash commands and modal submits stayed muted after an earlier decline. Both are one mistake: I picked a lane instead of a boundary. Teardown now runs immediately after _hm_admit_event, the single admission gate every entry path shares. dropped event -> latch survives, stale send blocked admitted event -> latch clears B2 — THE LATCH KEY SPLIT ON ':', WHICH IS A MISTAKE I ALREADY FIXED ONCE. _latch_key did str(chat_id).split(":", 1)[0], so !room:tenant-a and !room:tenant-b both keyed !room: a decline in one Matrix room muted another, and inbound from one cleared the other's refusal. egress.py ::_session_ids stopped doing exactly this in round 4 and I reintroduced it three rounds later. Parent identity is never recoverable from identifier TEXT. Thread coverage is now structural: _thread_parent looks the relationship up in the recorded auto-thread map. B3 — AUTHORIZATION AND DISPATCH USED DIFFERENT CONFIG SNAPSHOTS. _handle_send retains one pconfig; the guard independently reloaded config. Across a transition the authorization snapshot could see a connector-only setup (exemption granted) while dispatch still held the native token and sent the unattested @handle itself. The guard now takes native_token from the SAME snapshot dispatch will use. A caller that omits it does not silently look like "no token". NB-1/2/3 also closed: real-object snapshot tests, an exception shield that faces a real exception, and send_follow_up no longer discards the connector's verdict (that discard is exactly how the edit lane laundered declines). MUTATIONS (all killed) latch key splits on colon again thread parent lookup disabled dispatch token ignored by guard tool drops the snapshot token admission teardown removed teardown moved BEFORE admission exception shield removed follow_up drops raw_response "admission teardown removed" SURVIVED first: I had tested the helper, not _handle_message. Added a test driving production _handle_message with admission stubbed both ways. Fifth caller-level gap on this branch. One self-inflicted bug caught before commit: I passed pconfig.token in _handle_react, which has no pconfig — a NameError on every reaction. 516 passed. * docs(relay): pin the latch's thread coverage limit as a deliberate trade _thread_parent only sees connector auto-threads, and that map is capped at 256 entries, so a user-created or evicted thread does not inherit its parent's latch. Documented at the site and asserted by a test, because the alternative - deriving parents from identifier text - is exactly what muted unrelated Matrix rooms in round 9. The primary control is unaffected: authorize_relay_target takes thread_id as part of the destination and attests it on every send (6 thread tests). * refactor(relay): one SendResult decline classifier for all 8 gateway lanes The extraction found a DEFECT, not just repetition. Eight gateway lanes each hand-rolled the unwrapping of a decline from a SendResult, and they did not agree. Six checked only raw_response. Two also checked the error text. A connector that answers with the uniform decline SENTENCE and no structured code - the documented contract for older connectors, per _approval_send_outcome - was therefore classified as an ordinary failure by those six lanes, so each treated a refusal as "editing unavailable" and retried through another op. Measured: text-only decline six-site check False two-site check True structured decline six-site check True two-site check True No content leaked, because the adapter latch classifies the transport dict directly and catches both shapes (verified: text-only decline still latches C1 and keeps SECRET off the wire). The cost was wrong verdicts and futile retries, not disclosure. declined_send(result) in gateway/relay/egress.py now owns this. It checks raw_response when structured, else the error text, and preserves the ambiguous exclusion - an ambiguous result is a transport outcome, so it must never read as a refusal. run.py keeps its own shape deliberately: that lane has three verdicts (ambiguous / declined / failed), so it checks ambiguous first and then delegates the boolean. MUTATIONS (all killed) helper drops the text-only branch helper drops the structured branch ambiguous no longer excluded draft lane decline check removed edit-failure lane decline check removed prompt verdict lane check removed slash-confirm lane check removed draft lane goes terminal on ANY failure (over-refusal direction) "draft lane decline check removed" SURVIVED first: _send_draft_frame had no test driving an unsuccessful send_draft at all. Added one, with an ordinary-failure control so the fix cannot silently become "one flaky frame mutes the chat". A non-unique anchor also masked the edit-failure lane on the first pass - the trap my own skill warns about. This closes the duplication that caused four of nine rounds of blockers: a new lane now calls one classifier instead of copying three lines. 519 passed. * fix(relay): latch identity, new-turn boundary, seal arming, ambiguity Round 10, four blockers, each reproduced before fixing. Two are my own regressions from the previous two rounds. B1 - ADMISSION IS NOT A NEW-TURN BOUNDARY. Round 9 moved teardown to just after _hm_admit_event. That is only an ADMISSION gate: an authorized message can be steered into a running session, answer a pending prompt, run a busy slash command, or be refused by the pause/drain gates - all without starting a turn. Each of those cleared the ACTIVE turn's refusal, and a later fallback from that turn reached the wire (probe: latch emptied, wire ops ['edit', 'send']). Teardown now runs after _claim_active_session_slot, the first point the runner OWNS a new turn. The new test drives production _handle_message through all four non-turn lanes plus the real new-turn path. B2 - LATCH IDENTITY OMITTED THE LOGICAL PLATFORM. One relay adapter fronts several platforms, so native ids collide. A Discord refusal for chat 42 was cleared by clear_egress_latch("telegram", "42") - the method took a platform and ignored it - and the Discord fallback then reached the connector. Keyed by normalized platform plus exact chat id; thread-parent expansion keeps the platform component. B3 - THE DIRECT DRAFT-SEAL PATH DID NOT ARM THE LATCH. _seal_open_draft posts through _attempt directly rather than _outbound, so a definite decline logged and returned but never latched. The immediate plain-send fallback was suppressed by the caller's own check; later same-turn sends were not (wire ['draft', 'draft', 'send'], the third frame carrying refused content). B4 - MY OWN REFACTOR MADE AMBIGUOUS RESULTS TERMINAL. send_draft's ambiguous projection discarded raw_response, so declined_send fell through to the error-text branch - and an ambiguous result whose text carries the decline marker ("... egress declined: ack lost") read as a DEFINITE refusal and terminated the run. Ambiguous means the frame may well have been delivered: a transport outcome, never an authorization one. Fixed on both layers: the projection carries the body (and the seal's ambiguous return is now explicit too), and declined_send's text-only branch - which cannot see the ambiguous flag - treats ack-lost text as transport ambiguity. Audited every SendResult projection in adapter.py for the same shape. MUTATIONS (all killed) latch key drops the platform clear_egress_latch ignores platform draft seal does not arm the latch ambiguous projection drops raw body declined_send infers decline from ack-lost text teardown back at admission 523 passed. * refactor(relay): split the terminal-decline latch out of the guard PR The latch moves to feat/p5-egress-decline-latch (pushed at 3cf45736d7, which retains the full history) for redesign. This PR keeps the authorization guard and the per-site decline checks. WHY. Across eleven review rounds the two halves behaved very differently. The guard is a PURE FUNCTION of the destination - its blockers were all "you asked the wrong question" (case sensitivity, nested ImportError, missing thread_id, config snapshot skew), each a one-line correction that then stayed fixed. Rounds 7-10 found nothing new in it. The latch is MUTABLE STATE WITH A LIFETIME living on RelayAdapter - an object registered once per process that holds the WebSocket and has no concept of a turn. Nine of its blockers reduce to three questions the adapter cannot answer: when does it end, who arms it, what is it keyed on. Every answer so far has been a proxy (a successful op, an inbound message, an admitted event, a claimed session slot) and every proxy was wrong in a lane found later. The per-site checks hold identical information on `st` - a PER-TURN object - and have produced zero blockers, because the state dies with the turn and nobody has to decide when it ends. The no-relaunder property does NOT depend on the latch. Measured on the real consumer path with the latch absent: a declined draft frame sets _egress_declined and puts nothing on the wire. Removal verified structurally rather than by eye: an AST diff of every symbol between HEAD and this tree reports only latch symbols gone, nothing added. That check caught two over-deletions my strip made - _on_inbound (consumed by a "next def" boundary) and _SEEN_INBOUND_MAX (a class constant inside the removed span). Both restored; 19 failures went to 0. ALSO: RESTORED A TEST I WRONGLY REPORTED AS PASSING. test_tool_guard_forwards_thread_id never made it into the repo - `git log -S` finds it in no commit - though round 5 recorded its mutant as killed. Dropping thread_id from the guard call therefore survived the entire tests/tools suite (146 passed). Written properly this time, driving the real _handle_send far enough to reach the guard. It now KILLS that mutant. MUTATIONS on this tree guard fault authorizes instead of refusing KILLED thread_id dropped from the guard call KILLED (was SURVIVED) handle exemption ignores native credential KILLED draft lane decline check removed KILLED prompt verdict lane check removed KILLED slash-confirm lane check removed KILLED 503 passed. * test(relay): close the phantom-coverage gaps the guard audit found The thread_id test that was reported as killing a round-5 mutant turned out never to have been committed. That is a reason to distrust the other claimed kills, so I re-ran every guard mutation against the COMMITTED tree instead of trusting the earlier reports. Result: 9 of 11 killed, and the two "SKIPPED" ones had non-unique anchors hiding SIX separate sites. Mutating those individually found three real survivors. CASE NORMALISATION (round 3, finding 3) WAS HALF-COVERED. test_relay_fronted_matching_is_case_insensitive varies the CONFIGURED name but always requests lowercase "discord", so it pins _relay_fronted's normalisation and nothing else. The REQUESTED name's `.lower()` was covered by nothing at all. Probe with it removed: relay_routed("Discord") -> False authorize("Discord", unattested) -> AUTHORIZED which is exactly the bypass round 3 reported, alive again and untested. Two further sites were untested in the OVER-REFUSAL direction: the attested store is keyed lowercase, so a mixed-case request missed its own attested set and refused legitimate traffic. attested_relay_targets' own normalisation was invisible to every existing test because they all monkeypatch that function away; it is now asserted against the real function with only its leaf sources stubbed. Three tests added. All six case sites now die when mutated. I also re-did the three fail-closed RelayRouteUnknown mutations properly. The first pass swapped whole lines and produced IndentationErrors, so "KILLED" there proved nothing but a syntax error. Neutralising each raise at correct indentation: all three genuinely KILLED. FINAL AUDIT ON THIS TREE — 17 mutations, zero survivors guard: thread_id dropped at the call site guard: react path unguarded guard: handle exemption ignores native credential guard: 3x fail-closed raise neutralised guard: 6x case-normalisation site classifier: ambiguous treated as a decline classifier: text-only decline branch removed lane: draft / stream-edit / prompt / slash-confirm checks removed 511 passed. * test(relay): make the stream-edit test fail for the right reason Review of 45835a282d raised one blocking issue and three non-blocking ones. All four are addressed; none was a production defect. BLOCKING — the stream-edit test failed on the double, not on a leak. test_declined_stream_edit_does_not_send_the_unseen_tail implemented only the GUARDED path in its consumer double. Removing either guard therefore raised AttributeError inside the fake before any send could be observed: guard 1 removed -> AttributeError: no attribute '_is_flood_error' guard 2 removed -> AttributeError: no attribute '_clean_for_display' Red, but for the wrong reason — the test could not have caught the leak it is named for. My own docstring claimed it drove the fallback and checked the wire; it did neither. The double now implements everything the UNGUARDED path reaches (_is_flood_error, _flood_strikes, _current_edit_interval, _last_edit_time, _notify_new_message, _try_strip_cursor, _clean_for_display, _fallback_prefix, _metadata_for_send). Both mutations now fail on real assertions: guard 1 removed -> assert consumer._egress_declined is True guard 2 removed -> AssertionError: the unseen tail reached the wire: ['send'] NON-BLOCKING 1 — a docstring claimed more than the test exercises. test_requested_platform_name_is_also_normalised described a mixed-case send_message(target="Discord:999") bypass. That entry point cannot reach it: _resolve_tool_target lowercases the platform at tools/send_message_tool.py:47 before the guard runs. The test still pins a real contract — the helpers must not assume a lowercased argument, for the gateway lanes and any future non-normalising caller — so the claim is narrowed to that rather than the test removed. NON-BLOCKING 2 — the module docstring said "every lane drives the REAL RelayAdapter". The stream tests drive mixin doubles by design, because the behaviour under test belongs to the adapter's CALLER. Docstring now distinguishes the two kinds. NON-BLOCKING 3 — latch-deletion residue in gateway/relay/adapter.py:418: return None return latched if surface_declines else None The second line was unreachable and referenced a name deleted with the latch. Removed, along with the 20-line comment block describing the latch as "the structural fix" — that mechanism now lives on feat/p5-egress-decline-latch, not here. The reviewer independently confirmed the large deletion: an AST census between 3cf45736d7 and f57a2298fa reports only latch symbols removed and nothing added. 511 passed. * docs(relay): correct three claims that outran the code Review of 41ce3cc765 found no new production defect but three overstated claims, one of them in my own commit message. 1. THE LATCH COMMENTARY WAS STILL THERE. My previous commit message said it removed "the 20-line comment block describing the latch as the structural fix". It removed only the unreachable statement. Twenty lines at adapter.py:361-380 still described a per-chat latch, a choke point and its scope rules - none of which exist on this branch. In a refusal-sensitive module that reads as coverage this branch does not have. Now removed for real. This is the same defect class as the tests: a claim that outran what the code does. I made it while fixing that class. 2. THE STREAM-TEST DOCSTRING OVERSTATED BOTH MUTANTS. It said the mutation "now fails on the assertion that a send reached the wire" - true of one guard, not both. Verified separately: remove the _on_edit_failure check -> dies on _egress_declined, never reaches the fallback remove the fallback early return -> dies on the wire: ['send'] Both are valid behavioural failures, which is what the blocker asked for; they are different observables and the docstring now says so. 3. Duplicate `from types import SimpleNamespace` from an earlier scripted insert; imports reordered. 112 tests pass in the four focused files. * fix(relay): close two authorization defects found in review Both were reproduced before fixing and both mutants are pinned. 1. A LIVE relay adapter whose fronts_platform() raised degraded into the config fallback. `_live_relay_fronted` returned None for every failure, and None means "no live adapter, use the config snapshot" — so a faulting adapter plus an empty/stale snapshot made the guard conclude "not relay-routed" and authorize an unattested destination, while resolve_delivery_transport asks that same adapter and still routes over the relay. Measured: relay_routed=False, verdict None for chat 999. Absence and fault now have separate return values: None only when there is no runner or no relay adapter; a live adapter that cannot answer raises RelayRouteUnknown. This is the third instance of this bug class in this file, and the first two were also mine. 2. An attested chat whose id equalled the requested THREAD id vouched for that thread. The `thread in attested` arm proved nothing about parentage. Measured: attested {"-100A", "7"} authorized (-100A, thread 7). Only the bound `parent:thread` form is accepted now. Nothing legitimate needed the bare arm — _session_entry_id records a threaded origin as f"{chat_id}:{thread_id}", and a thread addressed as its own channel arrives as chat_id and passes the parent check. The existing test blessed the bare form via parametrize, so it PINNED the defect. Corrected, plus negative controls for the sibling-chat and other-parent cases and a positive control proving genuine absence still takes the config path (otherwise fix 1 would break native-only deploys). Merged origin/main (was 22 behind). 428 passed via scripts/run_tests.sh; full 10-row mutation ledger re-killed on the merged tree, none dying on an exception rather than an assertion. * fix(relay): only a missing adapter is absence; everything else is a fault Reviewer BLOCKER, reproduced before fixing. Two more paths where a PRESENT relay adapter still degraded into the config snapshot: 1. `fronts_platform` may be a property or descriptor, so the ATTRIBUTE LOOKUP can raise — and the lookup sat inside the absence handler. Probed with a raising property plus an empty snapshot: live=None, routed=False, verdict=None, i.e. an unattested target authorized. The previous test made an already-retrieved METHOD raise, so it could not reach this. 2. A present adapter with no usable `fronts_platform` returned None for the same reason. An adapter that cannot say what it fronts is broken, not absent, so it now raises too. Also found by my own spot-check while the review ran: the nested imports of `gateway.config` / `gateway.run` inside the live probe shared the broad handler, so a broken installation degraded to the snapshot as well. Probed with a healthy-adapter positive control in the same run — healthy refused the unattested target, faulted authorized it. `_relay_fronted` one function below already drew this exact distinction for its own import. The boundary is now: `relay is None` is the ONLY absence. Everything about a present adapter — attribute access, callability, the call itself, and the imports needed to reach it — is a fault and raises RelayRouteUnknown. This is the fourth variant of absence-vs-fault in this file and all four were mine. The lesson is in the code as a comment rather than in a commit message nobody re-reads. Four controls keep genuine absence benign: no runner, no relay adapter in the runner, a real ModuleNotFoundError naming the gateway package, and the configured-attested-target-still-sends case. 434 passed via scripts/run_tests.sh; 9-row mutation ledger re-killed including both new guards, none dying on an exception. * fix(relay): invert the live probe to fail closed by default Reviewer BLOCKER round 2, reproduced: reading the adapter registry can also raise. A runner whose `adapters.get()` raised gave relay_present=True, live=None, routed=False, verdict=None — unattested discord:999 authorized. That was the FIFTH boundary in one function with the same defect: the call, the attribute lookup, a non-callable attribute, the nested imports, and now the registry lookup. Each round I patched the reported boundary and the defect moved one statement up. The cause was the shape, not the statements: the function asked "did something go wrong?" and answered None, and None MEANS "no live adapter, use the config snapshot" — so every statement was a new chance to fail open, and every new statement would have been too. Inverted rather than patched a sixth time. Each `return None` now sits behind an explicit narrow check that cannot itself be the fault (no runner, no adapters, no relay key, gateway package genuinely absent), and one outer handler turns anything else into RelayRouteUnknown. A statement added inside this function is now fail-CLOSED by default. Verified all six fault shapes raise (call, attribute, missing method, registry .get, .adapters property, runner ref) and all five absence shapes stay benign, plus a liveness control where the config snapshot disagrees with a healthy adapter and the adapter still wins. Four new tests, including the two absence controls that keep native-only and CLI deployments working. 438 passed via scripts/run_tests.sh. Mutation ledger: 8 killed. One survivor recorded as a proven equivalent mutant — widening `if not registry` to `or {}` is behaviourally identical because `{}.get()` returns None, i.e. the same absence; it is a readability guard.	2026-09-08 17:51:35 +10:00
Ben Barclay	fef0e16fe1	fix(relay): re-dial once with a fresh token before treating a 4401 as revocation (#102602) ... * fix(relay): re-dial once with a fresh token before treating a 4401 as revocation A 4401 close after a successful handshake was read unconditionally as the connector having revoked this gateway's per-gateway secret (opt-out), so the transport latched auth_revoked, the adapter went relay_disabled, and all messaging stopped until a manual restart. But the connector sends the same plain 4401 'unauthorized' for an EXPIRED upgrade token (make_upgrade_token TTL is 300s). Scale-to-zero makes that routine: the instance is suspended while a re-dial is in flight, the token was minted before the freeze, the dial completes on resume with a token past its TTL, the connector refuses it with 4401, and the gateway misreads an expired token as a revoked credential. Production incident 2026-09-02 - the connector DB secret was never revoked. Fix, in gateway/relay/ws_transport.py: - The first post-handshake 4401 is provisional. The reader schedules ONE immediate re-dial (_redial_with_fresh_token) that bypasses the reconnect backoff; _dial_and_start mints a fresh token on every call. The backoff supervisor design is untouched. - Only a 4401 against that fresh token (either refused at the upgrade or closed after a descriptor on that connection, tracked by dial generation) latches auth_revoked. Terminal behaviour is otherwise unchanged. - If the fresh dial fails for a non-auth reason, hand off to the normal backoff supervisor. - Read the Close frame reason (_close_reason_of, sibling of _close_code_of). A 4401 whose reason is exactly 'expired' never latches revocation and takes the normal reconnect path - forward-compatible hook for the connector change landing separately. - disconnect() cancels the one-shot retry task alongside the supervisor. Tests (tests/gateway/relay/test_ws_transport.py, real websockets server): - 4401 once, next dial accepted -> reconnected, auth_revoked False, exactly 2 dials. - 4401 on every dial -> auth_revoked True after exactly one retry (2 dials), no supervisor, no further dials. - 4401 reason 'expired' (once and repeated) -> never latched, reconnects via the normal supervisor. - Existing 7d-B tests keep passing (4401 before any handshake stays retryable; the revoking-every-dial stub still latches). * fix(relay): tolerate a partially built transport in disconnect() teardown Three teardown tests construct WebSocketRelayTransport via object.__new__ without __init__, so the new _auth_retry attribute was absent and disconnect() raised AttributeError. Read it with getattr like the other optional teardown handles. * fix(relay): one live dialer — the fresh-token retry is a flag on the next dial, not a second dialer Review (round 1) found a race: a reader that dies with a provisional 4401 while the backoff supervisor is already mid-dial started _redial_with_fresh_token as a SECOND concurrent dialer; both installed sockets/readers and the supervisor could overwrite the accepted retry socket (3 dials, wrong socket). Now a provisional 4401 sets _auth_retry_pending; _dial_and_start consumes it and stamps _auth_retry_generation on whichever dialer performs the next dial. The reader arms a dialer only when none is live (_dialer_running), and an upgrade-time 4401 on that generation latches revocation from either dialer (_latch_if_fresh_token_refused). The reader also iterates its captured ws handle, not self._ws. Regression test reproduces the race with a deterministic fake connect; it fails with the _dialer_running guard removed. * fix(relay): a dial whose reader died mid-hello is a failed dial; the retry marker survives network failures Review round 2: - BLOCKER: with one-live-dialer, a reader that dies while its own dialer is still inside _dial_and_start (hello in flight) arms nothing — that is the dialer's job — but the dialer then returned 'connected', leaving no socket, no reader, no dialer. _dial_and_start now raises ConnectionError when the reader it installed has already finished, so both dialers take their normal failure path (retry -> supervisor; supervisor -> backoff). - MAJOR: _auth_retry_pending was consumed before websockets.connect, so a connect-time network failure un-marked the retry and the NEXT dial's real fresh-token 4401 read as another first strike (revocation never latched). The marker is now consumed only when the token reaches an auth outcome: upgrade accepted (stamp the generation) or upgrade 4401'd (judge it). Two regression tests, each mutation-checked red against its own guard.	2026-09-08 16:22:15 +10:00
Teknium	4810074d73	fix: retain completions until explicit adapter admission	2026-09-07 14:16:57 -07:00
Teknium	561897db59	fix: keep admitted heartbeats in their owning conversation	2026-09-07 14:16:57 -07:00
Teknium	bf1bf7515a	fix: retry Kanban wakes until adapter admission	2026-09-07 14:16:57 -07:00
Teknium	a247012dc1	fix(gateway): retain conversation route anchors for Kanban callbacks ... Carry canonical scope_id and parent_chat_id through session context and reply metadata. Stamp slash-created subscriptions with the routed source profile, not the notifier process profile. The gateway facade only wires the topical metadata helper and existing context binding. Two real gateway/DB invariants reproduced missing anchors and wrong owner before implementation. Related: #101196 and #101397. Co-authored-by: Brooklyn Nicholson <brooklyn.bb.nicholson@gmail.com>	2026-09-07 14:16:57 -07:00
Teknium	30b3ca16f4	fix(kanban): deliver routed profile notifications on the authorized transport ... Authorize route-only profiles using the ordered canonical route matcher and served-profile set at both claim and delivery. Preserve secondary credential boundaries, retry denied routes, and keep scope/parent anchors plus transport provenance on synthetic wakes. Install the destination runtime scope rather than inheriting the notifier's scope; a removed profile cannot wake as primary. Slim forward-port of the direction in #101196/#101397 and #93863 (#93851). Canonical scope_id takes precedence over the guild alias and live chat cache. Two route invariants and two runtime-scope invariants reproduced red first. Co-authored-by: Brooklyn Nicholson <brooklyn.bb.nicholson@gmail.com> Co-authored-by: liuhao1024 <sunsky.lau@gmail.com>	2026-09-07 14:16:57 -07:00
Teknium	9ee3d129b4	fix: wake idle process watches on their owning profile transport ... Salvage #82561's idle watch consumer through the existing drain, retaining notify-off suppression and retrying failed injections. Preserve #102647's secondary-profile ownership for reconstructed sources, preflight, synthetic completion turns, and raw process progress/final notices. Unavailable transports defer rather than borrowing the primary bot or losing the event. Keep retained transport provenance and alias-aware relay resolution. Add three invariant tests and an offline real-process/Discord lifecycle eval. Co-authored-by: trwpang <134544126+trwpang@users.noreply.github.com> Co-authored-by: holny <holny@foxmail.com>	2026-09-07 14:16:57 -07:00
Teknium	67161511d1	fix: retain async completions while delivery owners are unavailable ... Preflight source-first transport resolution and parent/API database readiness before spending any durable delivery attempt, including every batch sibling. Unavailable targets remain retryable; terminal targets retain their drop semantics and stateless API completions remain durable display rows, not turns. Minimal combined salvage of #82704 and #96086; adjacent eligibility, profile adapter selection and idle watch-consumer work remain separate. Co-authored-by: Screaming Sun <5552699+eventh0riz0n@users.noreply.github.com> Co-authored-by: fangliquanflq <fangliquan@qq.com>	2026-09-07 14:16:57 -07:00
Teknium	d6867ab459	fix: admit trusted busy wakes without changing queued human input ... Salvage the busy-auth ordering fix from #95602. Gateway-owned wakes have no external identity; keep external and plugin authentication unchanged. Preserve pending human text by appending wakes through the existing FIFO instead of base-adapter text merging. Co-authored-by: Robert Montelongo <ramontelongo22@gmail.com>	2026-09-07 14:16:57 -07:00
Teknium	59eb509f4c	fix: refund heartbeat admissions that never enter agent execution ... Bind settlement to the exact adapter task and event. Rejected or cancelled preparation refunds the existing claim; cancellation after the agent runner starts remains counted. Keep profile-scoped callback context and the manager replacement guard. A fire count is not outbound delivery proof. Drop departed routes rather than executing their stale schedule. Slim accounting-invariant salvage of #93174; preserve current direct adapter dispatch instead of reviving its FIFO/inflight implementation. Prior art #92858. Co-authored-by: Finn763 <165816600+Finn763@users.noreply.github.com> Co-authored-by: fangliquanflq <fangliquan@qq.com>	2026-09-07 14:16:57 -07:00
Teknium	27fa0b7eef	fix: keep heartbeat watches in their route and profile lifecycle ... Retry startup restoration on every poll, including an empty registry. Resolve current session identity after compression and scope each watch independently, preserving direct idle adapter admission and busy coalescing. Slim redo of #80208, #80225 and #80273. Co-authored-by: Gr1mmJ4w <ahmetsonersancak@anadolu.edu.tr> Co-authored-by: Drexuxux <drexux0@gmail.com> Co-authored-by: pierrenode <298902573+pierrenode@users.noreply.github.com>	2026-09-07 14:16:57 -07:00
Teknium	be154517a8	fix: restore gateway heartbeat watches after restart ... Recover active watches from current persisted session origins and exact route keys, reading heartbeat state off-loop in each source's profile. Failed scans leave watches intact for the poller's next retry. Start the heartbeat poller even when startup restores no watches. Slim synthesis of #92660, #98310 and #98313, with earlier restart recovery prior art from #92594. The integration poller calls restore_heartbeat_watches on every poll, including empty registries. Co-authored-by: chelsealong <chelsealong@126.com> Co-authored-by: liuhao1024 <sunsky.lau@gmail.com> Co-authored-by: fangliquanflq <fangliquan@qq.com>	2026-09-07 14:16:57 -07:00
Teknium	1ec22acca0	fix(gateway): stop departed session heartbeats at reset boundaries ... Clear the departed schedule using the route-owned database when ending a conversation, so stale watches cannot fire after reset and resuming the archived session cannot resurrect the schedule. Compression migration already archives its parent and remains unchanged. Adjacent lifecycle reports: #80273 by pierrenode and #80208 by 0xGr1mm. This follow-up covers durable reset cleanup, not their poller changes.	2026-09-07 14:16:57 -07:00
Teknium	3114916ee4	fix(gateway): carry accepted-input ownership through persistence ... Namespace delivery markers and assign fresh keyless turn identities instead of inferring ownership from IDs or process-local row baselines. Query only marker existence on the canonical live compression continuation and ancestors. Preserve raw reply IDs and exclude metadata from provider wire messages. Expand the two existing invariants with resumed cross-chat ID collisions, a real independent SQLite writer, reaped siblings, and archived-history allocation controls. All 20 full-handler checkpoints and 63 targeted tests pass.	2026-09-07 14:11:18 -07:00
Teknium	f120ea7149	fix(gateway): exclude observations from accepted-turn ownership	2026-09-07 14:11:18 -07:00
Teknium	136d80d040	fix(gateway): retain one durable owner for failed input turns	2026-09-07 14:11:18 -07:00
kshitijk4poor	e5382cd823	test(qqbot): exercise the real dm session key in the existing approval-click test ... The added test was a copy of test_approval_click_once_maps_to_once with only the key's chat_type changed; retarget the original to the key build_source actually emits. Both branches stay: approval keys carry "dm" (build_source), update-prompt keys carry event.scene ("c2c") — a comment records why.	2026-09-08 02:26:31 +05:30
penginman	2ff990c13f	fix(qqbot): authorize approval clicks for dm session keys ... PR #30737 added authorization checks for approval button clicks but hardcoded chat_type == 'c2c'. C2C sessions are actually created with chat_type='dm' (build_source at L1278, L1488), so the check always rejects DM approval buttons as unauthorized. Accept both 'c2c' and 'dm' for direct-message session keys.	2026-09-08 02:26:31 +05:30
kshitijk4poor	2f1609a86c	refactor: sms AIOHTTP_AVAILABLE flag; ElicitationHandler call_context defaults to a no-op thunk; drop stale TYPE_CHECKING/type-ignore in two tests ... Self-review follow-ups on the F821 sweep: - plugins/platforms/sms/adapter.py: the optional-import block now sets AIOHTTP_AVAILABLE like the homeassistant / webhook / whatsapp_cloud adapters, and both call sites test the flag. Removes the `if not aiohttp is not None:` double negation left by inlining `_aiohttp_available()`. - tools/mcp_tool_sampling.py: `call_context` defaults to `lambda: None` so the use site is a single call instead of an Optional guard; the only None caller was a test. The `from __future__ import annotations` was noise (`Context` is a runtime import). Comment names the actual cycle (mcp_tool_server_run imports this module). - gateway/platforms/helpers.py: drop the `from __future__ import annotations` — the only MessageEvent annotations are attribute-target locals, which are never evaluated. - tests/gateway/test_telegram_audio_vs_voice.py, test_video_context_note.py: module-level `from gateway.run import GatewayRunner` like the ~100 sibling files; the TYPE_CHECKING block + `# type: ignore[name-defined]` were contradicting each other. (tests/e2e/conftest.py and test_feishu.py keep TYPE_CHECKING deliberately: they stub telegram/discord before importing, and FeishuAdapter is gated on optional lark_oapi.) Mutation check: neutralising the thunk read (`captured = None`) fails test_captured_context_is_replayed_in_consent_call; restored → 14/14 green. ty on the three touched production files vs origin/main: 0 new, 6 resolved.	2026-09-07 22:47:33 +05:30
kshitijk4poor	ab2f4602de	refactor: MessageEvent to gateway/platforms/event.py; ElicitationHandler takes a call_context thunk ... Breaks the two import cycles that forced Protocol stand-ins in the F821 sweep, so the two sites now name the real types. gateway/platforms/event.py (new leaf): MessageType, ProcessingOutcome, MessageEvent moved out of base.py verbatim. Their only dependency is gateway.session.SessionSource; base.py imported helpers.py at module level, so helpers could not name MessageEvent. Now TextBatchAggregator is typed by the real MessageEvent. 249 importers repointed (`from gateway.platforms.base import` -> `.event`, preserving each import's layout); gateway.platforms.__init__ re-exports from .event. The three revert-scheduled PLUGIN-COMPAT pointers that named these symbols (gateway.slash_commands → MessageType, dingtalk → MessageType, photon → ProcessingOutcome) and their COMPAT_MANIFEST rows now target gateway.platforms.event. Docs updated: ADDING_A_PLATFORM.md, adding-platform-adapters.md (en + zh-Hans). tools/mcp_tool_sampling.py: ElicitationHandler no longer holds a back-reference to its MCPServerTask (mcp_tool imports sampling, so the task type cannot be named there). It only ever read owner._pending_call_context, so it takes `call_context: Callable[[], Context | None]` and MCPServerTask passes `lambda: self._pending_call_context`. The consent call is one `functools.partial`, run directly or inside the captured Context. ty on the 11 touched production files vs origin/main: 0 new diagnostics, 14 resolved. (The one `source: SessionSource = None` diagnostic moves with the class; typing it Optional exposes ~60 unguarded call sites — separate follow-up.) Tests: tests/gateway + tests/plugins + tests/tools + touched files, 18,235 passed; the 31 failures reproduce identically on origin/main (macOS /private/tmp, systemd socket, long-path fixtures, live-service tests).	2026-09-07 22:47:33 +05:30
kshitijk4poor	c5ff900761	fix: resolve the 33 F821 undefined names outside tui_gateway / feishu / godmode ... Sweep of `ruff check . --select F821 --target-version py311`: 2,234 hits. 2,201 are left alone on purpose: tui_gateway (2,169; bind_module rebinds bodies onto server.py globals, all names verified to resolve there), the Feishu adapter (27; globals().update() SDK binding) and the godmode script (5; dead standalone script). The other 33 were all genuine defects. No lint config change; no TYPE_CHECKING escape hatches — every annotation names a real, imported type; ty on the touched files: 0 new diagnostics. - gateway/slash_commands.py: HISTORY_UNREADABLE never imported after #102117 → NameError on the /btw error branch (same one-liner as #102952). - gateway/platforms/whatsapp_common.py: `-> Path` return annotation with no Path import (the body uses `_Path`). Never raised at runtime thanks to `from __future__ import annotations`, but `typing.get_type_hints()` and ty both fail on it. - gateway/run.py: ActivityProvenance imported at module level (agent.session_activity has no gateway deps); stringly annotation and the lazy in-function import are gone. - tools/patch_parser.py: PatchResult imported at module level; real return annotation. The "avoid circular import" lazy import guarded a cycle that does not exist (file_operations_common never imports patch_parser). - gateway/platforms/helpers.py: base.py imports helpers at module level, so MessageEvent cannot be named here; TextBatchAggregator only reads .text and .source, so it is typed by a BatchableEvent Protocol that MessageEvent satisfies structurally. - tools/mcp_tool_sampling.py: mcp_tool imports this module, so MCPServerTask cannot be named here; ElicitationHandler only reads owner._pending_call_context, typed by an ElicitationOwner Protocol. - plugins/platforms/sms/adapter.py: aiohttp is an optional dep ([messaging] extra) → module-level try/except ImportError binding `aiohttp = web = None`, the pattern the homeassistant / webhook / whatsapp_cloud adapters already use. Retires three lazy in-function imports and the `_aiohttp_available()` wrapper; `_handle_webhook` typed `web.Request -> web.Response`. - plugins/platforms/teams/summary_writer.py: plain module-level `import httpx` — httpx is a hard core dependency (pyproject `httpx[socks]==0.28.1`), so the lazy import and the "imported on every CLI start" docstring premise were both wrong (plugin discovery never imports this module; it is reached only via the Teams adapter / meeting pipeline). Tests: - tests/hermes_cli/test_config.py: a test body orphaned by the wave-1 prune (6b81590c55) sat inside the class as dead code with self/tmp_path unbound — header restored, so the v11→12 custom_providers migration is covered. - tests/tools/test_mcp_tool.py: @staticmethod recursing on `self` in the win32 branch; call portalocker directly. - tests/test_background_review_list_shapes.py: main() still ran 3 pruned tests. - tests/agent/test_cursor_optimizations_parity.py: bench() used names only imported inside a sibling test. - GatewayRunner / FeishuAdapter / Dict / Optional: missing imports.	2026-09-07 22:47:33 +05:30
Teknium	39ed610f8c	feat(cron): create paused jobs without a scheduling race ... Persist paused state, timestamp, reason and no first trigger in the original locked creation write. Forward the same boolean contract across CLI, tool, gateway API and dashboard API, validating at the store boundary. Preserve explicit operator force-run behavior and normal enabled creation. The live CLI probe also caught the command shim dropping failure return codes; forward them so invalid creation reports exit 1 rather than success. Credit earlier atomic-creation work in #78935 and #94952 and the focused implementation in #104578. The broader manifest staging layer is not imported. Co-authored-by: Konstantin Khlopkov <konstantin.khlopkov93@gmail.com> Co-authored-by: Chloé DuPont <321112755+misschloedupont@users.noreply.github.com>	2026-09-07 08:27:50 -07:00
doryani-agent	2a980fbcbd	fix(update): let systemd clients outwait legitimate unit transactions ... Salvage the unit-budget implementation from #104745, replacing its test matrix with two invariant tests and covering the sibling graceful start. Keep unprivileged property reads, finite fallbacks, real manager errors, and post-restart health verification. Native disposable user unit: old client timed out after 15.03 seconds; new client completed the same 16-second stop transaction in 16.13 seconds. The unit stayed active with a new PID; missing-unit errors stayed errors. Co-authored-by: Teknium <127238744+teknium1@users.noreply.github.com>	2026-09-07 08:20:09 -07:00
Teknium	9da8c63b1a	fix(display): preserve localized estimate markers and headroom labels	2026-09-07 08:13:01 -07:00
Teknium	04767e7aaa	fix(display): distinguish estimated context from provider usage	2026-09-07 08:13:01 -07:00
Teknium	d9833c5615	fix(gateway): resolve busy origin privacy in routed profile	2026-09-07 07:12:06 -07:00
Teknium	7d50f99fbb	fix(gateway): honor privacy policy in busy message origins ... Reuse the effective gateway config and shared session platform policy before hashing model-facing metadata. Preserve original routing state and cover enabled/disabled redaction across all busy injection routes.	2026-09-07 07:12:06 -07:00
Teknium	97fb4756fc	fix(gateway): retain alternate and parent source identities ... Address independent review: include existing alternate and parent routing fields, and distinguish event message ID from source message ID without inferring a reply target. Expanded live probe first failed on parent_chat_id, then passed with the additional fields.	2026-09-07 07:12:06 -07:00
Teknium	0461da8e6f	fix(gateway): retain original source fields in busy injections ... Trim salvage of #104047: preserve the shared gateway injection boundary, but keep lossless JSON entirely per message. Do not change the system prompt, steer ABI, or synthesize a delivery target. Live handler-to-agent A/B verified; serialized directory tests and independent review pending. Co-authored-by: joaomarcos <joaomarcosdias444@gmail.com>	2026-09-07 07:12:06 -07:00
Teknium	fd3565deec	fix: remove dedicated user-facing output cap controls	2026-09-07 06:15:43 -07:00
Teknium	d79575cb89	fix(slack): preserve explicit suspension after timer removal	2026-09-07 06:10:54 -07:00
Teknium	34e512ae58	fix(sessions): remove remaining timer migration and guidance	2026-09-07 06:10:54 -07:00
Teknium	1481a0de96	docs(gateway): describe persistent sessions without reset timers	2026-09-07 06:10:54 -07:00
Teknium	1d5d059410	fix(gateway): stop time-triggered conversation rotation	2026-09-07 06:10:54 -07:00
liuhao1024	342967058c	fix(agent): interpolate the live backups dir into corruption recovery guidance ... The corrupt-cause recovery guidance hardcoded `~/.hermes/backups/` while every other path in the same message follows the active HERMES_HOME (`{db_path}` is already interpolated). A custom-home or named-profile deployment was told to restore from a directory that may not exist at all, mid data-loss incident. Both sites (turn-completion explainer and gateway startup broadcast) now interpolate `<hermes_root>/backups` via get_default_hermes_root(), matching hermes_cli/backup.py's real backup location. Fixes #104250	2026-09-07 06:06:20 -07:00
Teknium	ea22528630	fix: reject blank unknown delivery destinations too	2026-09-07 06:00:05 -07:00
Teknium	33c1bb885c	fix: reject unknown delivery targets and allow API session preflight ... Salvage only the demonstrated delivery and session-header fixes. Leave queue admission, other CORS expansion and unrelated optimizations out of this bug pass. Co-authored-by: DevvGwardo <25094504+DevvGwardo@users.noreply.github.com> Co-authored-by: Frowtek <frowte3k@gmail.com>	2026-09-07 06:00:05 -07:00
Teknium	80b3346eee	fix: publish deferred room retries after discussion cleanup ... Resolve task sources and committed member messages from the durable log, not disposable policy projections. Record late outcome receipts without reactivating settled discussions; retain frozen prompts and retry behavior. Slim redo of the durable-log and late-publication portions of #104020. Unlike that proposal, retain retries and do not hide reconstruction errors. Also retain the source after the bounded thread transcript ages it out. Refs #104007 Co-authored-by: Halldrix <12357213+Halldrix@users.noreply.github.com>	2026-09-07 05:58:52 -07:00
Teknium	7e77401ad0	refactor: read retry deadlines only from the ledger	2026-09-07 04:46:20 -07:00
Teknium	af34ba3c01	fix: keep flood retry wakeups off the event loop and retain two invariants	2026-09-07 04:46:20 -07:00
Alexander Russell	5495c29cf8	fix(gateway): recognise every definite flood refusal, not only the canonical one ... The redelivery hook keyed on the canonical flood_control:<seconds> result, so two real refusals slipped past it and armed no timer, leaving the reply for the next restart. A short wait that outlived the send retries raised instead of failing closed, and an edit refused again after its inline wait returned the platform's raw text. Both now fail closed canonically, the second carrying the new delay rather than the first refusal's. The ledger also accepts a row still carrying the platform's own wording, so a row persisted by an unnormalized path is dated from the delay it states instead of the generic default. Without that a boot sweep claims it at once and spends its one attempt inside the penalty. Matching requires the flood wording as well as a delay, so an unrelated retry suggestion is never read as a flood. Six new assertions fail without this change. 770 passed across the ledger, Telegram, send-retry and queued suites.	2026-09-07 04:46:20 -07:00
Alexander Russell	e41e5e236b	fix(gateway): read the flood re-arm ledger synchronously so a mid-sweep refusal is not lost ... Round-2 review. Making _arm_flood_timers_for_waiting_rows read the ledger in a worker thread introduced a race: a flood refusal recorded during that thread's yield had its own _schedule_flood_redelivery request declined (the timer still held the slot), and the timer then cleared its slot on a snapshot taken before the new row committed, leaving that reply with no timer until the next reconnect or restart. The read is a single indexed SELECT; doing it synchronously keeps the arm decision atomic with respect to concurrent schedule requests. A test drives a refusal during the timer's own redelivery send and asserts the same timer arms it.	2026-09-07 04:46:20 -07:00
Alexander Russell	289ece2e59	fix(gateway): adopted flood rows clear resume flags and legacy profiles reach the timer ... Second review pass on the flood-retry change. - sweep_recoverable returns a dead owner's not-yet-due flood row flagged `adopted` (with its `not_before`) instead of dropping it from the result, so _claim_pending_obligations clears its session's resume_pending flag like every other claimed row; the answer is in the ledger and the turn must not be re-run at boot. _redeliver_claimed_obligations skips adopted rows and still arms the timer for them. - A legacy row without adapter_profile is normalised to 'default' when the boot sweep claims or adopts it: the runtime sweep matches profiles exactly and the timer asks for 'default', so an adopted NULL row could only wake the timer without ever being sent. - A sleeping timer is replaced by a shorter refusal's timer; the shorter one re-arms for the longer row after its sweep. A timer already sweeping is never cancelled from outside. - pending_flood_retries is read in a worker thread like the other ledger calls. - Adoption tests seed a distinct dead-owner stamp and assert ownership moves. - Scratch tags and long comment lines removed.	2026-09-07 04:46:20 -07:00
Alexander Russell	678b0649ab	fix(gateway): mark every flood redelivery and keep a released flood claim on the timer ... Review on the first cut reproduced two gaps. The raw UTF-16 length of the stored reply said nothing about how many requests the adapter made: MarkdownV2 escaping turns 3000 dots into 6000 units, two Telegram messages, and the send result does not say which chunk the platform refused. Drop the length-based certainty (and its helper and constant) and mark every flood redelivery with the rate-limit marker, at runtime and at boot. The cost is a marker on a reply nothing of which was delivered; the alternative was a silent duplicate. Releasing an unsent runtime claim always wrote send_path_degraded, so a flood row whose resume flag could not be cleared (or whose adapter vanished before dispatch) left the flood timer's list and stayed stranded until a reconnect or restart. The claimed row now carries its pre-claim error and the release writes it back, so the row waits the platform's figure once more and is sent on the next timer.	2026-09-07 04:46:20 -07:00
Alexander Russell	ae900cba9c	fix(gateway): redeliver a flood-refused final reply once the penalty passes, without a false duplicate marker ... The Telegram adapter fails a flood-controlled final send closed as flood_control:<seconds> so the send coroutine never sleeps a long penalty (#91969), on the understanding that the delivery ledger owns the wait. The ledger did not: sweep_failed_for_runtime only replayed send_path_degraded rows, so a flood-refused row sat in 'failed' until the next restart, whose sweep_recoverable then redelivered it hours late prefixed with "Recovered reply, the gateway restarted during delivery, so this may be a duplicate". Observed: a reply refused at 08:58 UTC (both the MarkdownV2 send and the plain fallback got flood_control:185) arrived at 12:15 UTC after a restart, labelled as a possible duplicate although the platform had never accepted it. Ledger (gateway/delivery_ledger.py): - flood_control rows are runtime-retryable, but only once their own deadline has passed: the refusal's updated_at plus the platform's wait (flood_not_before). Neither an early timer nor a reconnect sweep spends a redelivery attempt inside the penalty window. - A flood refusal of a reply that fits in one Telegram message (4096 UTF-16 units) proves non-delivery, so that redelivery carries no duplicate marker. A chunked reply may have had its first chunk accepted before the refusal and keeps the marker. - Claiming a flood row clears the stale refusal (last_error NULL, state 'attempting'), so a resend interrupted before mark_delivered is seen as uncertain by the next boot and gets the marker. - At boot, a dead owner's flood row that is not yet due is adopted (owner re-stamped, no attempt spent) instead of being resent early. - pending_flood_retries() lists this process's waiting flood rows per adapter identity with the earliest deadline. Runner (gateway/run_startup.py): - _schedule_flood_redelivery arms one timer per adapter identity that runs the existing runtime sweep after the wait (capped at 15 minutes per sleep; the row's deadline, not the timer, decides eligibility, so a capped timer wakes early, sends nothing, and re-arms for the remainder). The slot stays occupied until the timer ends and only the running timer may arm its successor into it, so a refusal during the sweep can never strand the row. - _arm_flood_timers_for_waiting_rows runs after every redelivery pass (boot and runtime), covering adopted rows, rows skipped as not yet due, and rows refused again. Adapter (gateway/platforms/base.py): _finalize_delivery_obligation arms the timer on a flood_control failure, best-effort inside the existing try. Tests: 35 in tests/gateway/test_delivery_ledger_flood_retry.py, with a controllable clock shared by ledger and runner. Each guard was mutation tested. Existing ledger, reconnect and redelivery suites (131 tests) pass.	2026-09-07 04:46:20 -07:00
Teknium	aacaeff42f	fix: share goal controls while messaging turns are active	2026-09-07 00:51:41 -07:00
Teknium	ebf2473325	refactor: share CLI goal commands across interactive surfaces ... Keep parsing, contracts, gates and persisted goal mutations in one dispatcher. Adapters retain authorization, rendering and scheduling; TUI drafting resolves the target session profile off the RPC reader. Document ACP as unsupported rather than implying a goal loop exists.	2026-09-07 00:51:41 -07:00
Teknium	3be1b87af1	fix(gateway): keep heartbeat admission on its watched route	2026-09-07 00:34:12 -07:00
yu-xin-c	febe68630f	fix(gateway): coalesce missed heartbeat ticks	2026-09-07 00:34:12 -07:00