fix(rest): re-attach to drain backlog before emitting terminal result#627
Draft
G4614 wants to merge 1 commit into
Draft
fix(rest): re-attach to drain backlog before emitting terminal result#627G4614 wants to merge 1 commit into
G4614 wants to merge 1 commit into
Conversation
A fast command over the cloud (Go runner) could return exit 0 with empty
stdout. When the WS attach drops before the runner flushes output (a proxy /
high-latency cut), attach_ws_pump probed GET /executions/{id}, saw
"completed", and emitted the exit code WITHOUT re-attaching — dropping the
stdout still sitting in the runner's replay backlog. Local `boxlite serve`
masked it (low latency, the exit frame always arrives in-band).
On a disconnect-then-Terminal probe, re-attach once (immediately, no backoff)
so the runner replays its backlog and we leave via its authoritative exit
frame. Bounded to a single attempt with fallback to the probed exit code, so
a runner that never sends a closing exit frame can't hang the pump.
Independent of boxlite-ai#563 (an sdks/c FFI drain fix): this is the REST client path,
so it reproduced on both main and boxlite-ai#563.
Reproducer: ws_terminal_probe_after_cut_must_not_drop_buffered_stdout drives
the WS pump against a mock that cuts the first attach, reports completed/0,
and serves the backlog only on re-attach. Without the fix it observes empty
stdout with a clean exit; with the fix it drains "hello\n".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Re-attach once to drain server-buffered stdout when the attach WebSocket is cut before the exit frame, fixing silent stdout loss.
Test plan
Two-sided (re-attach disabled vs applied), toggled on the branch since the test ships with the fix:
ws_terminal_probe_after_cut_must_not_drop_buffered_stdout— in-process mock-WS: the first attach is cut before the exit frame,GET /executions/{id}reports completed/exit 0, and the backlog (hello\n) is served only on re-attach.""— clean exit 0, output dropped"hello\n"— backlog drainedleft:"" right:"hello\n")Orthogonal to #563 (an
sdks/cFFI drain fix at the SDK layer): this is the REST client attach path, and the loss reproduced on bothmainand the #563 branch. Tradeoff: the re-attach replays the runner's full backlog without an offset, so a partial prefix delivered before the cut can be duplicated — this matches existingStillRunning/Unavailablereconnect semantics and is strictly preferable to silent loss (offset-based replay is out of scope).