') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ', 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); fix(core): retry replay timeouts without exiting by NathanColosimo · Pull Request #3385 · vercel/workflow · GitHub
Skip to content

fix(core): retry replay timeouts without exiting - #3385

Merged
NathanColosimo merged 4 commits into
mainfrom
codex/retry-replay-timeout-without-exit
Aug 7, 2026
Merged

fix(core): retry replay timeouts without exiting#3385
NathanColosimo merged 4 commits into
mainfrom
codex/retry-replay-timeout-without-exit

Conversation

@NathanColosimo

@NathanColosimoNathanColosimo commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Summary

  • replace the replay-budget process.exit(1) path with a dedicated ReplayTimeoutRetryError
  • let queue-handler rejection request redelivery in every World, while a durable terminal run_failed write acknowledges the delivery
  • remove the obsolete processExitTriggersQueueRedelivery World capability
  • align newly created Postgres jobs and migrated pg-boss jobs with the existing Core delivery ceiling

Root cause

Core intentionally exited the Node.js process when a replay exceeded its per-invocation budget. On Fluid Compute, multiple requests can share that process, so retrying one workflow delivery terminated unrelated co-resident requests as well. The request crash and replay warning from the incident match this path: request crash, replay warning.

New contract

  1. Replay-timeout attempts 1 through WORKFLOW_REPLAY_TIMEOUT_MAX_RETRIES reject the current queue handler with ReplayTimeoutRetryError.
  2. The World queue treats that rejection like any other delivery failure and redelivers the same message with an incremented attempt.
  3. The next attempt writes run_failed with REPLAY_TIMEOUT and returns, which acknowledges the terminal delivery.
  4. If the terminal event write fails, the rejection propagates so the queue retries instead of silently leaving the run nonterminal.
  5. Core never intentionally terminates the host process.

New Postgres jobs now permit delivery 49, where Core records MAX_DELIVERIES_EXCEEDED. Existing Graphile jobs retain the retry limit stored when they were queued; migrated pg-boss jobs are created with the new limit.

Verification

  • pnpm --filter @workflow/core test — 91 files, 1,996 passed and 3 expected failures
  • pnpm --filter @workflow/world-local test — 14 files, 518 passed
  • pnpm --filter @workflow/world-vercel test — 20 files, 362 passed
  • pnpm --filter @workflow/world-postgres test — 5 files, 169 passed
  • builds and typechecks pass for Core, World, world-local, world-vercel, and world-postgres
  • focused red/green coverage verifies Core rejection versus terminal acknowledgement and rejection propagation through local, Vercel, and Postgres queues
  • Simplify review completed with three parallel reviewers
  • Quality Code review completed
  • final Autoreview panel: Codex and Claude both reported zero findings; aggregate verdict patch is correct at 0.96 confidence

Release

This PR targets the v5 beta line on main. The same host-process crash exists in v4 stable, so this correctness fix should be backported through the repository automatic stable backport flow after merge.

@changeset-bot

changeset-botBot commented Aug 7, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 90a3a05

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 20 packages
NameType
@workflow/corePatch
@workflow/worldPatch
@workflow/world-vercelPatch
@workflow/world-postgresPatch
@workflow/buildersPatch
@workflow/cliPatch
@workflow/nextPatch
@workflow/nitroPatch
@workflow/vitestPatch
@workflow/web-sharedPatch
@workflow/webPatch
workflowPatch
@workflow/world-testingPatch
@workflow/world-localPatch
@workflow/astroPatch
@workflow/nestPatch
@workflow/rollupPatch
@workflow/sveltekitPatch
@workflow/vitePatch
@workflow/nuxtPatch

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

@vercel

vercelBot commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

@github-actions

github-actionsBot commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

🧪 E2E Test Results

All tests passed

E2E Test Summary

Summary
PassedFailedSkippedTotal
✅ ▲ Vercel Production293205003432
✅ 💻 Local Development329004543744
✅ 📦 Local Production329004543744
✅ 🐘 Local Postgres329004543744
✅ 🪟 Windows31200312
✅ 📋 Other206804282496
✅ vercel-multi-region270027
Total152090229017499
Details by Category

✅ ▲ Vercel Production

AppPassedFailedSkipped
✅ astro-node127029
✅ astro-quickjs127029
✅ example-node127029
✅ example-quickjs127029
✅ express-node127029
✅ express-quickjs127029
✅ fastify-node127029
✅ fastify-quickjs127029
✅ hono-node127029
✅ hono-quickjs127029
✅ nextjs-turbopack-node15204
✅ nextjs-turbopack-quickjs15204
✅ nextjs-webpack-node15204
✅ nextjs-webpack-quickjs15204
✅ nitro-node127029
✅ nitro-quickjs127029
✅ nuxt-node127029
✅ nuxt-quickjs127029
✅ sveltekit-node146010
✅ sveltekit-quickjs146010
✅ vite-node127029
✅ vite-quickjs127029

✅ 💻 Local Development

AppPassedFailedSkipped
✅ astro-stable-node130026
✅ astro-stable-quickjs130026
✅ express-stable-node130026
✅ express-stable-quickjs130026
✅ fastify-stable-node130026
✅ fastify-stable-quickjs130026
✅ hono-stable-node130026
✅ hono-stable-quickjs130026
✅ nextjs-turbopack-canary-node137019
✅ nextjs-turbopack-canary-quickjs137019
✅ nextjs-turbopack-stable-node15600
✅ nextjs-turbopack-stable-quickjs15600
✅ nextjs-webpack-canary-node137019
✅ nextjs-webpack-canary-quickjs137019
✅ nextjs-webpack-stable-node15600
✅ nextjs-webpack-stable-quickjs15600
✅ nitro-stable-node130026
✅ nitro-stable-quickjs130026
✅ nuxt-stable-node130026
✅ nuxt-stable-quickjs130026
✅ sveltekit-stable-node14907
✅ sveltekit-stable-quickjs14907
✅ vite-stable-node130026
✅ vite-stable-quickjs130026

✅ 📦 Local Production

AppPassedFailedSkipped
✅ astro-stable-node130026
✅ astro-stable-quickjs130026
✅ express-stable-node130026
✅ express-stable-quickjs130026
✅ fastify-stable-node130026
✅ fastify-stable-quickjs130026
✅ hono-stable-node130026
✅ hono-stable-quickjs130026
✅ nextjs-turbopack-canary-node137019
✅ nextjs-turbopack-canary-quickjs137019
✅ nextjs-turbopack-stable-node15600
✅ nextjs-turbopack-stable-quickjs15600
✅ nextjs-webpack-canary-node137019
✅ nextjs-webpack-canary-quickjs137019
✅ nextjs-webpack-stable-node15600
✅ nextjs-webpack-stable-quickjs15600
✅ nitro-stable-node130026
✅ nitro-stable-quickjs130026
✅ nuxt-stable-node130026
✅ nuxt-stable-quickjs130026
✅ sveltekit-stable-node14907
✅ sveltekit-stable-quickjs14907
✅ vite-stable-node130026
✅ vite-stable-quickjs130026

✅ 🐘 Local Postgres

AppPassedFailedSkipped
✅ astro-stable-node130026
✅ astro-stable-quickjs130026
✅ express-stable-node130026
✅ express-stable-quickjs130026
✅ fastify-stable-node130026
✅ fastify-stable-quickjs130026
✅ hono-stable-node130026
✅ hono-stable-quickjs130026
✅ nextjs-turbopack-canary-node137019
✅ nextjs-turbopack-canary-quickjs137019
✅ nextjs-turbopack-stable-node15600
✅ nextjs-turbopack-stable-quickjs15600
✅ nextjs-webpack-canary-node137019
✅ nextjs-webpack-canary-quickjs137019
✅ nextjs-webpack-stable-node15600
✅ nextjs-webpack-stable-quickjs15600
✅ nitro-stable-node130026
✅ nitro-stable-quickjs130026
✅ nuxt-stable-node130026
✅ nuxt-stable-quickjs130026
✅ sveltekit-stable-node14907
✅ sveltekit-stable-quickjs14907
✅ vite-stable-node130026
✅ vite-stable-quickjs130026

✅ 🪟 Windows

AppPassedFailedSkipped
✅ nextjs-turbopack-node15600
✅ nextjs-turbopack-quickjs15600

✅ 📋 Other

AppPassedFailedSkipped
✅ e2e-local-dev-nest-stable-node130026
✅ e2e-local-dev-nest-stable-quickjs130026
✅ e2e-local-dev-tanstack-start-node130026
✅ e2e-local-dev-tanstack-start-quickjs130026
✅ e2e-local-postgres-nest-stable-node130026
✅ e2e-local-postgres-nest-stable-quickjs130026
✅ e2e-local-postgres-tanstack-start-node130026
✅ e2e-local-postgres-tanstack-start-quickjs130026
✅ e2e-local-prod-nest-stable-node130026
✅ e2e-local-prod-nest-stable-quickjs130026
✅ e2e-local-prod-tanstack-start-node130026
✅ e2e-local-prod-tanstack-start-quickjs130026
✅ e2e-vercel-prod-nest-node127029
✅ e2e-vercel-prod-nest-quickjs127029
✅ e2e-vercel-prod-tanstack-start-node127029
✅ e2e-vercel-prod-tanstack-start-quickjs127029

✅ vercel-multi-region

AppPassedFailedSkipped
✅ nextjs-turbopack2700

📋 View full workflow run

@github-actions

github-actionsBot commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

📊 Workflow Benchmarks

commit 90a3a05 · Fri, 07 Aug 2026 20:25:29 GMT · run logs

Backend: vercel · app: nextjs-turbopack

MetricScenarioBest (ms)P75 (ms)P90 (ms)P99 (ms)Samples
TTFSstep1280 (+38%) 🔻1357 🔴 (+24%) 🔻1444 🔴 (+23%) 🔻1494 🔴 (-6.0%)30
TTFSstream250 (-75%) 💚1453 🔴 (+36%) 🔻1472 🔴 (+36%) 🔻1557 🔴 (+33%) 🔻30
TTFShook + stream1418 (+13%)1668 🔴 (+20%) 🔻1687 🔴 (+14%)1751 🔴 (-12%)30
STSO1020 steps (inline)102 (+17%) 🔻132 (+1.5%)148 (-5.7%)224 (-3.9%)1019
WO1020 steps133134 (+2.4%)133134 (+2.4%)133134 (+2.4%)133134 (+2.4%)1
SLstream latency91 (+9.6%)117 🔴 (-7.9%)132 🔴 (-5.0%)251 🔴 (+72%) 🔻30
SOstream overhead (text)108 (+1.9%)176 (-13%)194 (-35%) 💚264 (-93%) 💚30
SOstream overhead (structured)119 (-1.7%)165 (-45%) 💚200 (-52%) 💚467 (-77%) 💚30
📈 STSO distribution vs main (inline / queue-hop histograms)

1020 steps (inline)

Cumulative STSO time: main 128954ms → this run 131559ms (Δ +2605ms, +2%)

 50-100 ms ┃ main 14 this 0 -14
100-150 ms ███████████████████████┃ main 880 this 929 +49
150-200 ms █┃ main 95 this 73 -22
200-250 ms ┃ main 20 this 11 -9
250-300 ms ┃ main 3 this 3 +0
300-350 ms ┃ main 5 this 3 -2
350-400 ms ┃ main 2 this 0 -2
📜 Previous results (2)

ae3c98d

Fri, 07 Aug 2026 19:32:23 GMT · run logs

vercel / nextjs-turbopack

MetricScenarioBest (ms)P75 (ms)P90 (ms)P99 (ms)Samples
TTFSstep1285 (+21%) 🔻1404 🔴 (+18%) 🔻1484 🔴 (+18%) 🔻1777 🔴 (±0%)30
TTFSstream245 (-78%) 💚1393 🔴 (+14%)1440 🔴 (+13%)1492 🔴 (+10%)30
TTFShook + stream1529 (+12%)1700 🔴 (+15%)1720 🔴 (+12%)1757 🔴 (+6.2%)30
STSO1020 steps (inline)64 (-48%) 💚126 (-25%) 💚146 (-25%) 💚268 (-23%) 💚1019
WO1020 steps127167 (-24%) 💚127167 (-24%) 💚127167 (-24%) 💚127167 (-24%) 💚1
SLstream latency85 (-27%) 💚107 🔴 (-36%) 💚120 🔴 (-42%) 💚165 🔴 (-74%) 💚30
SOstream overhead (text)110 (-25%) 💚152 (-30%) 💚185 (-33%) 💚4118 🔴 (+1070%) 🔻30
SOstream overhead (structured)104 (-34%) 💚150 (-39%) 💚189 (-54%) 💚275 (-95%) 💚30

86d2324

Fri, 07 Aug 2026 03:48:52 GMT · run logs

vercel / nextjs-turbopack

MetricScenarioBest (ms)P75 (ms)P90 (ms)P99 (ms)Samples
TTFSstep229 (-68%) 💚1351 🔴 (+25%) 🔻1388 🔴 (+25%) 🔻1425 🔴 (+27%) 🔻30
TTFSstream225 (-4.7%)1380 🔴 (+30%) 🔻1407 🔴 (+28%) 🔻1677 🔴 (+50%) 🔻30
TTFShook + stream353 (-20%) 💚1532 🔴 (+7.9%)1560 🔴 (+4.2%)1669 🔴 (-3.3%)30
STSO1020 steps (inline)88 (-20%) 💚145 (-31%) 💚167 (-41%) 💚281 (-46%) 💚1019
WO1020 steps147293 (-28%) 💚147293 (-28%) 💚147293 (-28%) 💚147293 (-28%) 💚1
SLstream latency92 (-12%)144 🔴 (-60%) 💚178 🔴 (-59%) 💚667 🔴 (-5.8%)30
SOstream overhead (text)125 (-17%) 💚218 (-30%) 💚300 (-22%) 💚756 (+4.6%)30
SOstream overhead (structured)118 (-28%) 💚226 (-17%) 💚428 (+31%) 🔻684 (-3.9%)30
ℹ️ Metric definitions & methodology

The collapsed STSO distribution section above buckets every step gap of the sequential-steps run (not a sampled window), split by whether the step ending the gap ran inline — in the same warm process as the step before it, so the gap is pure framework overhead — or after a queue-hop — the first step of a fresh process, which pays queue dispatch, client reinit and event-log replay. Bars overlay the two runs: is main, marks where this run lands, bridges the gap when this run has more samples in a bucket.

Best/P75/P90/P99 deltas compare against the most recent benchmark run on main at the time of this run. 🔻 flags a delta worse than +15%, 💚 one better than −15%.

Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window)

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 · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost

🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000

All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor (clientStart) right before start(), so the CI runner’s request and its path through api.vercel.com sit outside every measured window. TTFS = in-deployment start() → first step body (turbo uses the in-process fast path, non-turbo the dispatch path), and includes the VQS dispatch hop plus any /flow cold start. STSO/WO are measured between step bodies on the deployment. SL is measured inside the workflow (parallel reader/writer steps), so it no longer includes the api.vercel.com read path.

Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the /flow invocation for a large fraction of runs, inflating P75+; the Best column shows the fastest (warm-start) sample for comparison.

@VaguelySeriousVaguelySerious left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Nit: think the changesets can be merged into one

@NathanColosimo

Copy link
Copy Markdown
ContributorAuthor

LGTM. Nit: think the changesets can be merged into one

fixed

@github-actions

Copy link
Copy Markdown
Contributor

Backport to stable failed for 74dbf81 due to a workflow error (backport job run).

This is usually an infrastructure problem (e.g. the configured AI model could not be found, an AI Gateway error, or an opencode crash) rather than a merge conflict. Check the job logs linked above for details.

Once the underlying issue is fixed, re-run the Backport to stable workflow manually via workflow_dispatch and paste this commit SHA into the ref input:

74dbf81d327b8574cca429b56757c7322a26b4ef

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@NathanColosimo@VaguelySerious