fix: retry backend connection failures and improve error logs - #4179
Conversation
…port failure `makeRequest` and `instrumentedFetch` only wrapped a `fetch` rejection as a retryable `TRANSPORT` / `STREAM_ERROR` when `getTransientTransportCode` found a code from a fixed allowlist on the error or its `cause` chain. Anything else was rethrown raw, and a raw `TypeError: fetch failed` is indistinguishable from a user throw by the time it reaches `classifyRunError`: the run failed as `USER_ERROR`, attributing a backend outage to customer code, and `isRetryableWorldError` never redelivered the queue message. The allowlist can only ever name failures someone has already seen, and the ones it misses are ordinary: h2 session errors (`ERR_HTTP2_GOAWAY_SESSION` — the shared events pool negotiates h2), TLS handshake failures, `ENETUNREACH`, and the `AggregateError` a happy-eyeballs connect raises, which hangs its codes off `errors[]` where a `cause` walk cannot see them. A rejection from `fetch` / `nodeHttpFetch` means no response was produced at all, so `describeTransportFailure` inverts the default: everything is a transport failure unless it is a request-construction fault (`ERR_INVALID_URL` and friends), which is permanent and must keep failing fast rather than burning the run's delivery budget re-forming the same broken request. Known codes still name themselves in the message, so existing failures report exactly what they reported before, including the `UND_ERR_CONNECT_TIMEOUT` retry branch. Agent selection and `Request` construction move out of the try blocks so the catch only ever sees the request on the wire. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Karthik Kalyan <105607645+karthikscale3@users.noreply.github.com>
… log The run-failure log prints `errorMessage` and the source-map-remapped `errorStack`, and neither says anything when the terminal error is a wrapper. `TypeError: fetch failed` is the canonical case: undici's wrapper carries that fixed message by design and a stack of pure `node:internal/` frames, all of which the formatter's framework-frame trim drops. The socket, DNS or TLS failure that actually happened lives one or two `cause` hops down, and nothing in the log pipeline read it. Same for the world layer's own wrapping, where the wrapper names the request and the cause names what went wrong with it. `formatErrorCauseChain` summarizes the chain, one `Name: message (CODE)` line per link, skipping the value itself (the log already prints that) and summarizing an `AggregateError`'s collected attempts, which is where a happy-eyeballs connect reports every address it tried. `composeLogLine` renders it as a `cause` row under the message it explains, and skips it when the stack body already spells the chain out. The field is undefined when there is no cause, so an ordinary user throw logs exactly as before. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-Authored-By: Karthik Kalyan <105607645+karthikscale3@users.noreply.github.com>
🦋 Changeset detectedLatest commit: 39cb5e7 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 |
📊 Workflow Benchmarkscommit Backend:
Streams
📈 STSO distribution vs main (inline / queue-hop histograms)1020 steps (inline) Cumulative STSO time: main 162443ms → this run 149939ms (Δ -12504ms, -8%) 📈 CRTT drill-down vs main (RTT distributions & profiles)RTT over stream progress (avg per tenth of stream, bars scaled min→max): RTT by chunk size (avg per log size bin, ~160B → ~12KB serialized, bars scaled min→max): Delivery jitter over stream progress (avg positive CDV per tenth of stream, bars scaled min→max): ℹ️ Metric definitions & methodologyStreams: first-chunk RTT (the stream-open path, before any buffering/backpressure), CRTT percentiles, and worst delivery stall (CDV max). Cells are medians across iterations; per-run values in the artifacts. No 🔴/🟢 marks until targets attach. The collapsed STSO distribution section above buckets every step gap, split inline (same warm process — pure framework overhead) vs queue-hop (fresh process — dispatch, reinit, replay). The collapsed CRTT drill-down: per-variant RTT histograms (fixed log bins, Best/P75/P90/P99 deltas compare against the most recent benchmark run on Metrics — TTFS: time to first step body (in-deployment start() → first step body) · Fan-out TTFS: fan-out time to first step (in-deployment start() → first of the parallel step bodies to complete) · Fan-out TTLS: fan-out time to last step (in-deployment start() → last of the parallel step bodies to complete, i.e. when the Promise.all resolves) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · CRTT: chunk round-trip time (per-chunk write → read latency, one clock domain: deployment → stream backend → same deployment) · CDV: chunk delay variation / delivery jitter (inter-arrival gap minus inter-write gap per seq-adjacent pair; skew-free; the row is each run's MAX positive value, so one stall moves it) Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · Promise.all(100 steps): 100 trivial no-op steps started together in a single Promise.all; Fan-out TTFS is the first of them to complete and Fan-out TTLS the last, both from the in-deployment clientStart, so their gap is the spread the runtime adds across the fan-out · paced control (100/s, 60B): the control: 300 tiny (~60B) deltas metronome-paced at 100/s — zero workload structure, so it reads the transport floor and flush cadence, and disambiguates transport-wide vs workload-specific when a replay row moves · size sweep (100/s, 160B-12KB): same pacing as the control with deltas padded in rotation across seven log-spaced sizes (~160B–12KB) — rotation decouples size from stream position, so it isolates whether chunk size causes latency · replay gateway-gpt-5.4-nano-2000t (1x): raw provider SSE cadence captured at the AI gateway boundary (gpt-5.4-nano, the most popular gateway model; per-token deltas p50 208B = the modal production chunk size), replayed exactly as measured — the typical customer's workload; its CDV is the typical customer's real delivery jitter · replay eve-gpt-5.6-sol-2000t (1x): a captured eve turn (gpt-5.6-sol, the most-used demanding eve model; ~2000 output tokens = production p50 turn length) replayed exactly as measured — eve's envelope protocol re-ships the cumulative message so sizes ramp 142B→13KB; the demanding outlier tenant's reality · replay eve-gpt-5.6-sol-2000t (2x): the same eve capture at 2x — the headroom/stress row; real fast-tier models emit the same chunk sizes at proportionally higher rate, so time compression is a faithful speed model · first chunk (pooled): every run's seq-0 RTT pooled across all stream scenarios — the first chunk precedes any workload differentiation, so pooling samples one shared stream-open path with exact percentiles Replay cadences (semantic sha256) — eve-gpt-5.6-sol-2000t 🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 All timestamps are deployment-side; runs are triggered in-deployment, so the CI runner and api.vercel.com sit outside every measured window. TTFS = Cold starts stay in the numbers (real bursty-workload latency, inflates P75+); Best is the warm floor. |
🧪 E2E Test Results✅ All tests passed
|
| Passed | Failed | Skipped | Total | |
|---|---|---|---|---|
| ✅ ▲ Vercel Production | 3662 | 0 | 685 | 4347 |
| ✅ 💻 Local Development | 3998 | 0 | 510 | 4508 |
| ✅ 📦 Local Production | 3998 | 0 | 510 | 4508 |
| ✅ 🐘 Local Postgres | 3998 | 0 | 510 | 4508 |
| ✅ 🪟 Windows | 320 | 0 | 2 | 322 |
| ✅ 🌐 Cross-language Conformance | 68 | 0 | 74 | 142 |
| ✅ vercel-http-transport | 823 | 0 | 143 | 966 |
| ✅ vercel-multi-region | 27 | 0 | 0 | 27 |
| ✅ vercel-ws-transport | 557 | 0 | 87 | 644 |
| Total | 17451 | 0 | 2521 | 19972 |
Details by Category
✅ ▲ Vercel Production
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-node | 133 | 0 | 28 |
| ✅ astro-quickjs | 133 | 0 | 28 |
| ✅ example-node | 133 | 0 | 28 |
| ✅ example-quickjs | 133 | 0 | 28 |
| ✅ express-node | 133 | 0 | 28 |
| ✅ express-quickjs | 133 | 0 | 28 |
| ✅ fastify-node | 133 | 0 | 28 |
| ✅ fastify-quickjs | 133 | 0 | 28 |
| ✅ hono-node | 133 | 0 | 28 |
| ✅ hono-quickjs | 133 | 0 | 28 |
| ✅ nest-node | 133 | 0 | 28 |
| ✅ nest-quickjs | 133 | 0 | 28 |
| ✅ nextjs-turbopack-node | 158 | 0 | 3 |
| ✅ nextjs-turbopack-quickjs | 158 | 0 | 3 |
| ✅ nextjs-webpack-node | 158 | 0 | 3 |
| ✅ nextjs-webpack-quickjs | 158 | 0 | 3 |
| ✅ nitro-node | 133 | 0 | 28 |
| ✅ nitro-quickjs | 133 | 0 | 28 |
| ✅ nuxt-node | 133 | 0 | 28 |
| ✅ nuxt-quickjs | 133 | 0 | 28 |
| ✅ python-node | 66 | 0 | 95 |
| ✅ sveltekit-node | 152 | 0 | 9 |
| ✅ sveltekit-quickjs | 152 | 0 | 9 |
| ✅ tanstack-start-node | 133 | 0 | 28 |
| ✅ tanstack-start-quickjs | 133 | 0 | 28 |
| ✅ vite-node | 133 | 0 | 28 |
| ✅ vite-quickjs | 133 | 0 | 28 |
✅ 💻 Local Development
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-stable-node | 134 | 0 | 27 |
| ✅ astro-stable-quickjs | 134 | 0 | 27 |
| ✅ express-stable-node | 134 | 0 | 27 |
| ✅ express-stable-quickjs | 134 | 0 | 27 |
| ✅ fastify-stable-node | 134 | 0 | 27 |
| ✅ fastify-stable-quickjs | 134 | 0 | 27 |
| ✅ hono-stable-node | 134 | 0 | 27 |
| ✅ hono-stable-quickjs | 134 | 0 | 27 |
| ✅ nest-stable-node | 134 | 0 | 27 |
| ✅ nest-stable-quickjs | 134 | 0 | 27 |
| ✅ nextjs-turbopack-canary-node | 160 | 0 | 1 |
| ✅ nextjs-turbopack-canary-quickjs | 160 | 0 | 1 |
| ✅ nextjs-turbopack-stable-node | 160 | 0 | 1 |
| ✅ nextjs-turbopack-stable-quickjs | 160 | 0 | 1 |
| ✅ nextjs-webpack-canary-node | 160 | 0 | 1 |
| ✅ nextjs-webpack-canary-quickjs | 160 | 0 | 1 |
| ✅ nextjs-webpack-stable-node | 160 | 0 | 1 |
| ✅ nextjs-webpack-stable-quickjs | 160 | 0 | 1 |
| ✅ nitro-stable-node | 134 | 0 | 27 |
| ✅ nitro-stable-quickjs | 134 | 0 | 27 |
| ✅ nuxt-stable-node | 134 | 0 | 27 |
| ✅ nuxt-stable-quickjs | 134 | 0 | 27 |
| ✅ sveltekit-stable-node | 153 | 0 | 8 |
| ✅ sveltekit-stable-quickjs | 153 | 0 | 8 |
| ✅ tanstack-start-node | 134 | 0 | 27 |
| ✅ tanstack-start-quickjs | 134 | 0 | 27 |
| ✅ vite-stable-node | 134 | 0 | 27 |
| ✅ vite-stable-quickjs | 134 | 0 | 27 |
✅ 📦 Local Production
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-stable-node | 134 | 0 | 27 |
| ✅ astro-stable-quickjs | 134 | 0 | 27 |
| ✅ express-stable-node | 134 | 0 | 27 |
| ✅ express-stable-quickjs | 134 | 0 | 27 |
| ✅ fastify-stable-node | 134 | 0 | 27 |
| ✅ fastify-stable-quickjs | 134 | 0 | 27 |
| ✅ hono-stable-node | 134 | 0 | 27 |
| ✅ hono-stable-quickjs | 134 | 0 | 27 |
| ✅ nest-stable-node | 134 | 0 | 27 |
| ✅ nest-stable-quickjs | 134 | 0 | 27 |
| ✅ nextjs-turbopack-canary-node | 160 | 0 | 1 |
| ✅ nextjs-turbopack-canary-quickjs | 160 | 0 | 1 |
| ✅ nextjs-turbopack-stable-node | 160 | 0 | 1 |
| ✅ nextjs-turbopack-stable-quickjs | 160 | 0 | 1 |
| ✅ nextjs-webpack-canary-node | 160 | 0 | 1 |
| ✅ nextjs-webpack-canary-quickjs | 160 | 0 | 1 |
| ✅ nextjs-webpack-stable-node | 160 | 0 | 1 |
| ✅ nextjs-webpack-stable-quickjs | 160 | 0 | 1 |
| ✅ nitro-stable-node | 134 | 0 | 27 |
| ✅ nitro-stable-quickjs | 134 | 0 | 27 |
| ✅ nuxt-stable-node | 134 | 0 | 27 |
| ✅ nuxt-stable-quickjs | 134 | 0 | 27 |
| ✅ sveltekit-stable-node | 153 | 0 | 8 |
| ✅ sveltekit-stable-quickjs | 153 | 0 | 8 |
| ✅ tanstack-start-node | 134 | 0 | 27 |
| ✅ tanstack-start-quickjs | 134 | 0 | 27 |
| ✅ vite-stable-node | 134 | 0 | 27 |
| ✅ vite-stable-quickjs | 134 | 0 | 27 |
✅ 🐘 Local Postgres
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-stable-node | 134 | 0 | 27 |
| ✅ astro-stable-quickjs | 134 | 0 | 27 |
| ✅ express-stable-node | 134 | 0 | 27 |
| ✅ express-stable-quickjs | 134 | 0 | 27 |
| ✅ fastify-stable-node | 134 | 0 | 27 |
| ✅ fastify-stable-quickjs | 134 | 0 | 27 |
| ✅ hono-stable-node | 134 | 0 | 27 |
| ✅ hono-stable-quickjs | 134 | 0 | 27 |
| ✅ nest-stable-node | 134 | 0 | 27 |
| ✅ nest-stable-quickjs | 134 | 0 | 27 |
| ✅ nextjs-turbopack-canary-node | 160 | 0 | 1 |
| ✅ nextjs-turbopack-canary-quickjs | 160 | 0 | 1 |
| ✅ nextjs-turbopack-stable-node | 160 | 0 | 1 |
| ✅ nextjs-turbopack-stable-quickjs | 160 | 0 | 1 |
| ✅ nextjs-webpack-canary-node | 160 | 0 | 1 |
| ✅ nextjs-webpack-canary-quickjs | 160 | 0 | 1 |
| ✅ nextjs-webpack-stable-node | 160 | 0 | 1 |
| ✅ nextjs-webpack-stable-quickjs | 160 | 0 | 1 |
| ✅ nitro-stable-node | 134 | 0 | 27 |
| ✅ nitro-stable-quickjs | 134 | 0 | 27 |
| ✅ nuxt-stable-node | 134 | 0 | 27 |
| ✅ nuxt-stable-quickjs | 134 | 0 | 27 |
| ✅ sveltekit-stable-node | 153 | 0 | 8 |
| ✅ sveltekit-stable-quickjs | 153 | 0 | 8 |
| ✅ tanstack-start-node | 134 | 0 | 27 |
| ✅ tanstack-start-quickjs | 134 | 0 | 27 |
| ✅ vite-stable-node | 134 | 0 | 27 |
| ✅ vite-stable-quickjs | 134 | 0 | 27 |
✅ 🪟 Windows
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ nextjs-turbopack-node | 160 | 0 | 1 |
| ✅ nextjs-turbopack-quickjs | 160 | 0 | 1 |
✅ 🌐 Cross-language Conformance
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ python | 68 | 0 | 74 |
✅ vercel-http-transport
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ example | 133 | 0 | 28 |
| ✅ express | 133 | 0 | 28 |
| ✅ hono | 133 | 0 | 28 |
| ✅ nextjs-turbopack | 158 | 0 | 3 |
| ✅ nitro | 133 | 0 | 28 |
| ✅ vite | 133 | 0 | 28 |
✅ vercel-multi-region
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ nextjs-turbopack | 27 | 0 | 0 |
✅ vercel-ws-transport
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ example | 133 | 0 | 28 |
| ✅ express | 133 | 0 | 28 |
| ✅ nextjs-turbopack | 158 | 0 | 3 |
| ✅ vite | 133 | 0 | 28 |
Sim WorldSimulated world deterministic testing for races. Traces 🟠 world-sim scenario book — 1 fail of 41 total
Full trace: |
About these numbersSizes are gzip; parentheses show the change against
|
VaguelySerious
left a comment
There was a problem hiding this comment.
AI review: blocking issues found
AI Review: Blockingpackages/world-vercel/src/events-v4.ts:167 still uses the old allowlist once response headers have arrived. An unrecognized socket or HTTP/2 failure while reading the event body is therefore propagated raw and can again be classified as a user error, even though it is the same backend connection failure this change is intended to retry. Please apply the transport classification to response-stream read failures as well and add coverage for a stream interrupted after headers. |
|
AI Review: Note packages/world-vercel/src/http-client.ts:648 retains a narrower recycler allowlist than the newly retryable failure set. In particular, an unknown HTTP/2 session error can now be retried while the warm process continues using the same unhealthy dispatcher. Please add coverage tying the new classification to recycler behavior, or document why the dispatcher always evicts these sessions itself. The retry semantics and failed-run cause output are user-visible, but this PR only updates the changeset. Please document the behavior in the user-facing docs. |
VaguelySerious
left a comment
There was a problem hiding this comment.
AI review: blocking issues found
AI Review: BlockingRe-review at 32c8544 confirms that packages/world-vercel/src/events-v4.ts:167 is still blocking approval. I added a disposable regression where createWorkflowRunEventsBatchV4 receives response headers and then its body fails with ERR_HTTP2_GOAWAY_SESSION. The call rejects with the raw Error: The session has been destroyed rather than StreamError, so withEventPostRetry does not recognize the backend failure as retryable. The blocked-port finding is fixed, but the post-header V4 path still needs to use the open-ended transport classification and cover this batch consumer. |
|
AI Review: Note Addressed the post-header V4 transport blocker in 954bc61. Response-body read failures now use the same open-ended transport classification as pre-header failures, so an unrecognized HTTP/2 session failure is surfaced as Validation: |
VaguelySerious
left a comment
There was a problem hiding this comment.
AI review: blocking issues found
karthikscale3
left a comment
There was a problem hiding this comment.
Addressed the remaining connection-pool and documentation review notes in 2373ca4. Both package builds pass; 3,195 core/world-vercel tests pass (3 expected failures, 1 skipped).
| 'ERR_HTTP2_GOAWAY_SESSION', | ||
| 'ERR_HTTP2_INVALID_SESSION', | ||
| 'ERR_HTTP2_SESSION_ERROR', | ||
| 'ERR_HTTP2_STREAM_ERROR', |
There was a problem hiding this comment.
Addressed the recycler review note in 2373ca4. Added GOAWAY, invalid-session, session-error, and stream-error codes to pool recycling. Pre- and post-header regressions now verify that GOAWAY failures remain StreamError, preserve their cause, and replace the shared pool after three failures. DNS/TLS/connect failures, request validation, and caller cancellation remain excluded from recycling.
|
|
||
| A connection failure does not prove that the backend rejected a write: it may have accepted it before the response was lost. Continue to make step side effects [idempotent](/docs/foundations/idempotency). | ||
|
|
||
| Failed-run logs include the underlying error causes and their codes, exposing socket, DNS, or TLS errors behind messages such as `TypeError: fetch failed`. If a cause cannot be read, the log includes `[unavailable cause]` and the run can still be recorded as failed. |
There was a problem hiding this comment.
Addressed the documentation review note in 2373ca4. Added user-facing docs for backend retries, HTTP/2 pool recovery, invalid URLs, write-outcome uncertainty, and cause-chain logs. Updated both package READMEs and the existing single changeset; the PR description links to the docs preview.
karthikscale3
left a comment
There was a problem hiding this comment.
Fixed both follow-up P2 findings in 39cb5e7. Both package builds and 3,212 core/world-vercel tests pass (3 expected failures, 1 skipped).
| 'ABORT_ERR', | ||
| 'UND_ERR_ABORTED', | ||
| 'ERR_HTTP2_STREAM_CANCEL', | ||
| ].includes(marker) |
There was a problem hiding this comment.
Fixed the V4 event-write retry regression. The helper now explicitly recognizes StreamError (the WorkflowWorldError.is() guard excludes subclasses) and retries eligible stream failures while excluding caller cancellations. Regression tests exercise interrupted step_completed batch responses through the actual event-write wrapper: GOAWAY and uncoded failures retry and observe the original write’s 409; cancellation sends no second request.
| // Undici validates request options and headers during dispatch, after | ||
| // Fetch has constructed the Request (e.g. unsupported Expect headers). | ||
| 'UND_ERR_INVALID_ARG', | ||
| 'UND_ERR_NOT_SUPPORTED', |
There was a problem hiding this comment.
Fixed permanent Undici request failures becoming retryable. UND_ERR_NOT_SUPPORTED and UND_ERR_INVALID_ARG now preserve the original rejection. Real Fetch regressions cover Expect: 100-continue and invalid Connection headers in both transport-error modes, plus the supported V4 backend-header configuration. Updated the existing changeset and docs.
|
Backport PR opened against |
What changed
Why
Network failures could fail workflows as user errors, with only an unhelpful
fetch failedmessage.Verification
Core and world-vercel builds and unit tests pass. Regression coverage includes request validation, cancellation, interrupted event-write retries, cause-chain logs, and connection-pool replacement.
Docs Preview
Backend connection failures