Repository navigation
fix(execution): let an unread fetch body release the guest event loop - #2067
Merged
Merged
Conversation
|
This PR was not deployed automatically as @eersnington does not have access to the Railway project. In order to get automatic PR deploys, please add @eersnington to your workspace on Railway. |
Contributor
📟 Pip-Boy ·
|
| package (linux-x64-gnu) | @latest |
base | this PR | Δ vs base | packages |
|---|---|---|---|---|---|
@rivet-dev/agentos-core |
458.2 MB | 325.9 MB | 325.9 MB | 0 | 10 (0) |
@rivet-dev/agentos-node-pty |
7.6 KB | 18.0 KB | 18.0 KB | 0 | 1 (0) |
@rivet-dev/agentos-posix |
253.6 MB | 253.6 MB | 253.6 MB | 0 | 7 (0) |
@rivet-dev/agentos-runtime-core |
253.6 MB | 253.6 MB | 253.6 MB | 0 | 6 (0) |
@rivet-dev/agentos-sandbox |
495.5 MB | 363.5 MB | 363.5 MB | 0 | 85 (0) |
@rivet-dev/agentos-toolchain |
130.8 KB | 141.2 KB | 141.2 KB | 0 | 2 (0) |
🧹 Rust dependencies
Skipped: this PR doesn't change any Rust code or dependencies.
🦀 Binaries
Skipped: this PR doesn't change any Rust code.
⏱ Timing
| job | wall time | slowest step |
|---|---|---|
changes |
29s | checkout · 26s |
zizmor |
9s | checkout · 3s |
footprint |
1m30s | Pack this commit · 27s |
⏭ self-test |
— | skipped |
⏭ native · ${{ matrix.platform }} |
— | skipped |
⏭ hygiene |
— | skipped |
report |
20s | setup-node · 6s |
🔭 Full CI trace for this commit
One OpenTelemetry trace of CI and Pip-Boy for adfc1cf: every job and step, with the sizes above attached. Run after CI finishes.
pnpm install --frozen-lockfile --filter 'pipboy...'
pnpm --filter pipboy pipboy trace --sha adfc1cfd57905c0e8ca86c6295b62a7bc742af9dAdd --otlp <url> to send it to any OTLP/HTTP collector.
Agent instruction: From a rivet-dev/agentos checkout, run the commands above, then read the trace file the last command prints. List the slowest jobs and steps and explain where CI time went.
The undici stream shim's finished() polled web streams with a ref'd 0 ms timer until they closed. An unread fetch body never closes, so the timer kept the guest process alive and busy. Watch the web-streams-polyfill state transition instead, so finished() holds no event-loop reference, matching Node's eos.
eersnington
force-pushed
the
fix/fetch-unread-body-liveness
branch
from
October 21, 2026 17:19
2f6d6b3 to
adfc1cf
Compare
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
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.
Fixes the remaining part of #1989.
A guest
fetchwhose response body was never read kept the guest process alive (over 90 s, or forever on a keep-alive loopback server), andjavascript.evaluate("(await fetch(url)).status")returnedtimed_out.finished()polled web stream state withsetTimeout(poll, 0). An unread body never closes, so a ref'd timer re-armed about every millisecond. The socket and keep-alive pool accounting were already correct.finished()now subscribes to the stream's state transition instead of polling, so it holds no event-loop reference, like Node'seos. An in-flight request still keeps the process alive.main