Uh oh!
There was an error while loading. Please reload this page.
fix(world-vercel): cancel v4 event frame stream on early exit to release undici connections - #2873
Conversation
🦋 Changeset detectedLatest commit: e3474ec The changes in this PR will be included in the next version bump. This PR includes changesets to release 17 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
|
📊 Workflow Benchmarkscommit Backend:
Avg deltas compare against the most recent benchmark run on Metrics — TTFS: time to first step body execution · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (time outside step bodies, client start → last step body exit) · SL: stream latency (first chunk write → visible to the reader) Scenarios — stream: one step that streams chunks back to the client; no hooks, so the run stays in turbo mode · hook + stream: registers a hook before the same streaming step, which exits turbo mode · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges 🟢/🔴 mark percentiles within/above target. Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120 TTFS/WO compare client vs deployment clocks and SL compares the step runner’s clock vs the client’s (NTP-synced in CI). WO ends at the last step body exit, the closest observable proxy for the final step-completion request. |
The straight reapply of #2547 awaited chunks.return?.()/reader.cancel() in decodeFrames' finally block, blocking every early-exit caller (getEventV4, every replay's list read) on the cancel's completion. On Vercel's Next.js (turbopack + webpack) Function lanes this hung indefinitely — confirmed via CI: every single E2E Vercel Prod run got stuck in "running" after its step completed, for the full 30-minute window, while all other frameworks passed cleanly in ~15 minutes. Same failure signature and same two CI lanes as #2807's awaited reader.cancel() bug in the core abort-stream reader — very likely the actual (undocumented) reason #2547 was reverted. Fix: fire-and-forget the cancel, matching #2807's pattern. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Approval notes: I reviewed the stream lifecycle and found no blocker or correctness regression. I verified cleanup on early return, break, and error paths; both the async-iterable and Web ReadableStream reader paths; detached cleanup error handling; unchanged chunk, empty-body, truncation, and end-sentinel decoding; the getEventV4 HTTP path; and the correctly scoped @workflow/world-vercel changeset. Locally, 31 targeted tests, package typecheck, and Biome checks passed. CI unit tests and every local and Vercel E2E lane are green, including Next.js Turbopack and Webpack.
Summary
Reapplies #2547, which was reverted in #2554 with no recorded rationale.
decodeFrames(the v4 event frame-stream reader) never cancelled its underlyingresponse.bodywhen a consumer stopped reading before EOF. With Node'sfetch/undici, a response body that is neither fully drained nor cancelled keeps its socket checked out of the connection pool — so every such read leaks a connection until keepalive timeout/GC.Two live read paths stop early by design and hit this:
getEventV4returns after the first frame (single-frame response)consumeListFrameStream(getWorkflowRunEventsV4/getEventsByCorrelationIdV4)breaks at the{_end:1}sentinelFix
packages/world-vercel/src/frames.ts:decodeFramesread loop intry/finallyand callchunks.return?.()on exit, which cancels the source stream (releasing the socket) on early break/return, normal completion, and error paths alike. No-op once drained.readerToIteratornow cancels its reader in afinally(the non-async-iterable fallback branch).Why not a straight reapply
The original #2547 diff
awaited the cancel inside thefinallyblock. Pushing that verbatim onto currentmainfirst (see commit history) hung every singleE2E Vercel Prod Tests (nextjs-turbopack)and(nextjs-webpack)run for the full 30-minute CI window — each run's step completed (step_completedobserved) but the run never reached a terminal event, because the SDK's own subsequent event read was blocked awaiting the cancel. All 10 other frameworks passed cleanly in ~15 minutes.This is the same failure signature and the same two CI lanes as #2807 ([world-local] Fix per-step AbortSignal latency), where an awaited
reader.cancel()in the core abort-stream reader hung specifically on Next.js's Vercel Function lanes because a service-backed World'scancel()can hit the network, and Next.js's runtime doesn't tolerate blocking on it the way other frameworks do. That PR's fix — fire-and-forget the cancel — is applied here too.This is very likely the actual (undocumented) reason #2547 was reverted in June, before that failure mode had a name.
Test plan
packages/world-vercel/src/frames.test.ts: asserts the underlying stream is cancelled when the consumer breaks early (for both the async-iterable andreaderToIteratorbranches), plus a guard that full consumption still decodes every frame. These pass unchanged with the fire-and-forget cancel — invoking.cancel()/.return()runs the underlying source's cancel algorithm synchronously; only awaiting completion is deferred.packages/world-vercel/src/events-v4.test.ts:getEventV4HTTP round-trip via undiciMockAgent, with a trailing frame the reader must never read.pnpm test(world-vercel) 235 passed,pnpm typecheckandbiome checkclean.