fix(gateway): follow async completions across compression - #64530
fix(gateway): follow async completions across compression#64530richkapp wants to merge 1 commit into
Conversation
c3cdeaf to
48b6ae2
Compare
48b6ae2 to
38f0227
Compare
|
Thanks for tracing the compression continuation case. The premise is verified on current main: The proposed resolver uses the existing lineage-aware No substantive correctness issue was found in the inspected diff. This is an automated hermes-sweeper review. |
Summary
/newor reopen SQLite session rows.Problem
The July 8 async-completion guard only validates the captured
gateway_session_idwhen it differs from the current gateway route.That leaves two compression cases broken:
sessions.jsonstill points at the ended compressed parent,pinned == currentbypasses the ended-row guard and the late completion can continue against the stale parent.This is a gateway follow-up to #55578, #57498, #57576, and #61993. It complements the classic-CLI ownership work in #64240; this PR does not touch CLI or TUI delivery.
Fix
For events carrying the captured parent session:
compression, resolve the transitive compression tip, require that tip to be live, and prove the current route belongs to the same lineage./new), fail closed.Blast radius
gateway_session_idis attached by the synthetic completion path from an event'sparent_session_id; that field is produced by async delegations, not terminal/background-process completions.GatewayRunner._handle_message; classic CLI and TUI paths are unchanged.end_sessionorreopen_session./newwins the race. A stale snapshot cannot overwrite a newer route, and an already-advanced compression route is idempotent.AsyncSessionDBandAsyncSessionStorekeep this work off the event loop.Verification
Broader gateway/delegation run:
The sole failure is the checkout's existing Feishu SDK capability check (
lark_oapi.ws.Clientlacksextra_ua_tagsin the local venv). The identical failure reproduces on a cleanorigin/mainworktree: 209 passed, 1 failed.Tested on Linux with Python 3.11.