chore(devbox): cap forwarded long-poll timeout and add client read margin#818
Merged
Conversation
…rgin Long-poll helpers forwarded timeout_seconds=remaining (often well above what the server honors) and left the client read timeout at the global 30s default. Cap the forwarded timeout_seconds at the server clamp (30s status, 25s exec) and set a per-request read timeout of server_hold + 5s so the client is never the party that aborts a long-poll. Defensive hygiene: this does not by itself eliminate held-stream cancels. Those are server-initiated (the h2 stream idle timeout racing the long-poll clamp) and are fixed server-side. Pairs with #817. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
gautam-rl
force-pushed
the
gautam/long-poll-read-timeout
branch
from
July 10, 2026 20:10
b14abba to
1037642
Compare
gautam-rl
changed the title
yoon-park-rl
approved these changes
Jul 10, 2026
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
2 participants
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.
Summary
Hygiene, not a bug fix — scoped down after validation (see below).
The
wait_for_statusand exec-await long-poll helpers forwardedtimeout_seconds = remaining(often far above what the server honors) and left the client read timeout at the global 30s default. This:timeout_secondsat the server clamp (30s status, 25s exec — no point asking for more than the server holds), andhttpx.Timeout(server_hold + 5s, connect=5.0)so the client is never the party that aborts a long-poll.Pairs with #817.
What this does NOT fix
The held-stream
CANCELs seen under load are server-initiated, not a client read-timeout race. Instrumenting the h2 layer during forced long-holds showed zero client-sent resets on both the currentmainand this branch; the cancels come from mux/Jetty's h2 stream idle timeout (inherited default 30s) racing the 30s long-poll clamp and firing first under load. That is fixed server-side (raise the mux stream idle timeout above the clamp), not here.So this PR is defensive hygiene: correct and harmless, but it does not change the observed cancel behavior. Merge or hold at your discretion.
Changes
_constants.py—LONG_POLL_CLIENT_BUFFER_SECONDS(5.0),STATUS_LONG_POLL_SERVER_MAX_SECONDS(30.0),EXEC_LONG_POLL_SERVER_MAX_SECONDS(25.0).lib/wait_for_status.py— cap forwardedtimeout_seconds; per-requesttimeout = httpx.Timeout(hold + buffer, connect=5.0).resources/devboxes/devboxes.py,resources/devboxes/executions.py— exec await paths pass the 25s clamp + matching read timeout.Note:
devboxes.py/executions.pyare generated; these await helpers are hand-patched the same way #817 patched them.🤖 Generated with Claude Code