Uh oh!
There was an error while loading. Please reload this page.
fix(core): preserve Hook retention in QuickJS - #3319
Conversation
🦋 Changeset detectedLatest commit: 8adf51f The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 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❌ Some tests failed ❌ Failed E2E Tests📋 Other (1 failed)e2e-vercel-prod-tanstack-start-quickjs (1 failed):
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 149536ms → this run 121240ms (Δ -28296ms, -19%) 1020 steps (queue-hop) Cumulative STSO time: main 2962ms → this run 2667ms (Δ -295ms, -10%) 📜 Previous results (2)342c64cTue, 04 Aug 2026 06:21:51 GMT · run logs
98692e4Tue, 04 Aug 2026 04:57:12 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 |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
The capability gate in dispatchPendingOps is swallowed by the terminal-drain call sites' try/catch (which exists to keep genuine drain failures from masking the workflow's own outcome). A retained hook that was never awaited only reaches the gate through that drain — so on an unsupporting World, a fire-and-forget retained hook completed the run normally with the retention silently dropped. Hoist assertHookRetentionSupported above the drain try/catch in both terminal branches. The drain runs before the run_completed / run_failed write, so the FatalError escapes to the replay loop's catch while the run is still non-terminal and records run_failed — mirroring the node engine, where the same error throws synchronously inside createHook() and a fire-and-forget retained hook can never complete the run. Suggested by the Vercel agent review.
No backport to The entire QuickJS engine is absent from To override, re-run the Backport to stable workflow manually via |
Summary
hook_createdeventRoot cause
The QuickJS hook shim created its own pending-operation object but omitted
experimental_minRetention. The host therefore persisted the Hook withouttokenRetentionUntil, and terminal-run cleanup made it unavailable immediately. The node VM path already forwarded the deadline correctly.Testing
pnpm turbo run build --filter='!./workbench/*'pnpm --filter @workflow/core test(1,905 passed; 3 expected failures)hookMinRetentionWorkflow - terminal Hook cannot resume and its token stays unavailable