fix(core): retry replay timeouts without exiting - #3385
Conversation
🦋 Changeset detectedLatest commit: 90a3a05 The changes in this PR will be included in the next version bump. This PR includes changesets to release 20 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 E2E Test SummarySummary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
✅ vercel-multi-region
|
📊 Workflow Benchmarkscommit Backend:
📈 STSO distribution vs main (inline / queue-hop histograms)1020 steps (inline) Cumulative STSO time: main 128954ms → this run 131559ms (Δ +2605ms, +2%) 📜 Previous results (2)ae3c98dFri, 07 Aug 2026 19:32:23 GMT · run logs
86d2324Fri, 07 Aug 2026 03:48:52 GMT · run logs
ℹ️ Metric definitions & methodologyThe 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: 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, 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 ( Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the |
VaguelySerious
left a comment
VaguelySerious
left a comment
There was a problem hiding this comment.
LGTM. Nit: think the changesets can be merged into one
fixed |
|
Backport to 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 |
2 participants
Summary
process.exit(1)path with a dedicatedReplayTimeoutRetryErrorrun_failedwrite acknowledges the deliveryprocessExitTriggersQueueRedeliveryWorld capabilityRoot 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
WORKFLOW_REPLAY_TIMEOUT_MAX_RETRIESreject the current queue handler withReplayTimeoutRetryError.run_failedwithREPLAY_TIMEOUTand returns, which acknowledges the terminal delivery.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 failurespnpm --filter @workflow/world-local test— 14 files, 518 passedpnpm --filter @workflow/world-vercel test— 20 files, 362 passedpnpm --filter @workflow/world-postgres test— 5 files, 169 passedpatch is correctat 0.96 confidenceRelease
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 automaticstablebackport flow after merge.