[core] Send the disposed hook's token from the QuickJS engine - #3773
Conversation
The two engines disagreed about what a disposal says. The node:vm engine has
always sent `eventData: { token }` on `hook_disposed`; the QuickJS engine sent
no `eventData` at all, even though the pending operation already carries the
token and already uses it to order same-token hook operations.
That matters to a world that keys a hook's token claim separately from the hook
itself, because releasing both means knowing which token this disposal is for.
Without it such a world has to look the token up before it can act, and the
same workflow does different work depending on which VM ran it — a difference
that surfaces as a backend-shaped bug rather than an engine one.
The field is omitted rather than sent as `undefined` when the operation carries
no token, since `PendingHookDispose.token` is optional and the two wire formats
disagree about how to encode an explicit `undefined`. A world reading it cannot
then tell this engine from a client too old to send one, which is a case it
already handles.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 3873b69 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 |
📊 Workflow Benchmarkscommit Backend:
Streams
📈 STSO distribution vs main (inline / queue-hop histograms)1020 steps (inline) Cumulative STSO time: main 147417ms → this run 138798ms (Δ -8619ms, -6%) 📈 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): 📜 Previous results (1)f3d26baMon, 24 Aug 2026 23:29:51 GMT · run logs
Streams
ℹ️ 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❌ Some tests failed ❌ Failed E2E Tests▲ Vercel Production (8 failed)python-node (8 failed):
🌐 Cross-language Conformance (9 failed)python (9 failed):
|
| Passed | Failed | Skipped | Total | |
|---|---|---|---|---|
| ❌ ▲ Vercel Production | 3570 | 8 | 742 | 4320 |
| ✅ 💻 Local Development | 3922 | 0 | 558 | 4480 |
| ✅ 📦 Local Production | 3922 | 0 | 558 | 4480 |
| ✅ 🐘 Local Postgres | 3922 | 0 | 558 | 4480 |
| ✅ 🪟 Windows | 320 | 0 | 0 | 320 |
| ❌ 🌐 Cross-language Conformance | 0 | 9 | 132 | 141 |
| ✅ vercel-http-transport | 817 | 0 | 143 | 960 |
| ✅ vercel-multi-region | 27 | 0 | 0 | 27 |
| ✅ vercel-ws-transport | 553 | 0 | 87 | 640 |
| Total | 17053 | 17 | 2778 | 19848 |
Details by Category
❌ ▲ Vercel Production
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-node | 132 | 0 | 28 |
| ✅ astro-quickjs | 132 | 0 | 28 |
| ✅ example-node | 132 | 0 | 28 |
| ✅ example-quickjs | 132 | 0 | 28 |
| ✅ express-node | 132 | 0 | 28 |
| ✅ express-quickjs | 132 | 0 | 28 |
| ✅ fastify-node | 132 | 0 | 28 |
| ✅ fastify-quickjs | 132 | 0 | 28 |
| ✅ hono-node | 132 | 0 | 28 |
| ✅ hono-quickjs | 132 | 0 | 28 |
| ✅ nest-node | 132 | 0 | 28 |
| ✅ nest-quickjs | 132 | 0 | 28 |
| ✅ nextjs-turbopack-node | 157 | 0 | 3 |
| ✅ nextjs-turbopack-quickjs | 157 | 0 | 3 |
| ✅ nextjs-webpack-node | 157 | 0 | 3 |
| ✅ nextjs-webpack-quickjs | 157 | 0 | 3 |
| ✅ nitro-node | 132 | 0 | 28 |
| ✅ nitro-quickjs | 132 | 0 | 28 |
| ✅ nuxt-node | 132 | 0 | 28 |
| ✅ nuxt-quickjs | 132 | 0 | 28 |
| ❌ python-node | 0 | 8 | 152 |
| ✅ sveltekit-node | 151 | 0 | 9 |
| ✅ sveltekit-quickjs | 151 | 0 | 9 |
| ✅ tanstack-start-node | 132 | 0 | 28 |
| ✅ tanstack-start-quickjs | 132 | 0 | 28 |
| ✅ vite-node | 132 | 0 | 28 |
| ✅ vite-quickjs | 132 | 0 | 28 |
✅ 💻 Local Development
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-stable-node | 134 | 0 | 26 |
| ✅ astro-stable-quickjs | 134 | 0 | 26 |
| ✅ express-stable-node | 134 | 0 | 26 |
| ✅ express-stable-quickjs | 134 | 0 | 26 |
| ✅ fastify-stable-node | 134 | 0 | 26 |
| ✅ fastify-stable-quickjs | 134 | 0 | 26 |
| ✅ hono-stable-node | 134 | 0 | 26 |
| ✅ hono-stable-quickjs | 134 | 0 | 26 |
| ✅ nest-stable-node | 134 | 0 | 26 |
| ✅ nest-stable-quickjs | 134 | 0 | 26 |
| ✅ nextjs-turbopack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-turbopack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-turbopack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-turbopack-stable-quickjs | 160 | 0 | 0 |
| ✅ nextjs-webpack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-webpack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-webpack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-webpack-stable-quickjs | 160 | 0 | 0 |
| ✅ nitro-stable-node | 134 | 0 | 26 |
| ✅ nitro-stable-quickjs | 134 | 0 | 26 |
| ✅ nuxt-stable-node | 134 | 0 | 26 |
| ✅ nuxt-stable-quickjs | 134 | 0 | 26 |
| ✅ sveltekit-stable-node | 153 | 0 | 7 |
| ✅ sveltekit-stable-quickjs | 153 | 0 | 7 |
| ✅ tanstack-start-node | 134 | 0 | 26 |
| ✅ tanstack-start-quickjs | 134 | 0 | 26 |
| ✅ vite-stable-node | 134 | 0 | 26 |
| ✅ vite-stable-quickjs | 134 | 0 | 26 |
✅ 📦 Local Production
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-stable-node | 134 | 0 | 26 |
| ✅ astro-stable-quickjs | 134 | 0 | 26 |
| ✅ express-stable-node | 134 | 0 | 26 |
| ✅ express-stable-quickjs | 134 | 0 | 26 |
| ✅ fastify-stable-node | 134 | 0 | 26 |
| ✅ fastify-stable-quickjs | 134 | 0 | 26 |
| ✅ hono-stable-node | 134 | 0 | 26 |
| ✅ hono-stable-quickjs | 134 | 0 | 26 |
| ✅ nest-stable-node | 134 | 0 | 26 |
| ✅ nest-stable-quickjs | 134 | 0 | 26 |
| ✅ nextjs-turbopack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-turbopack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-turbopack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-turbopack-stable-quickjs | 160 | 0 | 0 |
| ✅ nextjs-webpack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-webpack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-webpack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-webpack-stable-quickjs | 160 | 0 | 0 |
| ✅ nitro-stable-node | 134 | 0 | 26 |
| ✅ nitro-stable-quickjs | 134 | 0 | 26 |
| ✅ nuxt-stable-node | 134 | 0 | 26 |
| ✅ nuxt-stable-quickjs | 134 | 0 | 26 |
| ✅ sveltekit-stable-node | 153 | 0 | 7 |
| ✅ sveltekit-stable-quickjs | 153 | 0 | 7 |
| ✅ tanstack-start-node | 134 | 0 | 26 |
| ✅ tanstack-start-quickjs | 134 | 0 | 26 |
| ✅ vite-stable-node | 134 | 0 | 26 |
| ✅ vite-stable-quickjs | 134 | 0 | 26 |
✅ 🐘 Local Postgres
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-stable-node | 134 | 0 | 26 |
| ✅ astro-stable-quickjs | 134 | 0 | 26 |
| ✅ express-stable-node | 134 | 0 | 26 |
| ✅ express-stable-quickjs | 134 | 0 | 26 |
| ✅ fastify-stable-node | 134 | 0 | 26 |
| ✅ fastify-stable-quickjs | 134 | 0 | 26 |
| ✅ hono-stable-node | 134 | 0 | 26 |
| ✅ hono-stable-quickjs | 134 | 0 | 26 |
| ✅ nest-stable-node | 134 | 0 | 26 |
| ✅ nest-stable-quickjs | 134 | 0 | 26 |
| ✅ nextjs-turbopack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-turbopack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-turbopack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-turbopack-stable-quickjs | 160 | 0 | 0 |
| ✅ nextjs-webpack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-webpack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-webpack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-webpack-stable-quickjs | 160 | 0 | 0 |
| ✅ nitro-stable-node | 134 | 0 | 26 |
| ✅ nitro-stable-quickjs | 134 | 0 | 26 |
| ✅ nuxt-stable-node | 134 | 0 | 26 |
| ✅ nuxt-stable-quickjs | 134 | 0 | 26 |
| ✅ sveltekit-stable-node | 153 | 0 | 7 |
| ✅ sveltekit-stable-quickjs | 153 | 0 | 7 |
| ✅ tanstack-start-node | 134 | 0 | 26 |
| ✅ tanstack-start-quickjs | 134 | 0 | 26 |
| ✅ vite-stable-node | 134 | 0 | 26 |
| ✅ vite-stable-quickjs | 134 | 0 | 26 |
✅ 🪟 Windows
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ nextjs-turbopack-node | 160 | 0 | 0 |
| ✅ nextjs-turbopack-quickjs | 160 | 0 | 0 |
❌ 🌐 Cross-language Conformance
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ❌ python | 0 | 9 | 132 |
✅ vercel-http-transport
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ example | 132 | 0 | 28 |
| ✅ express | 132 | 0 | 28 |
| ✅ hono | 132 | 0 | 28 |
| ✅ nextjs-turbopack | 157 | 0 | 3 |
| ✅ nitro | 132 | 0 | 28 |
| ✅ vite | 132 | 0 | 28 |
✅ vercel-multi-region
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ nextjs-turbopack | 27 | 0 | 0 |
✅ vercel-ws-transport
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ example | 132 | 0 | 28 |
| ✅ express | 132 | 0 | 28 |
| ✅ nextjs-turbopack | 157 | 0 | 3 |
| ✅ vite | 132 | 0 | 28 |
Sim WorldSimulated world deterministic testing for races. Traces 🟠 world-sim scenario book — 1 fail of 41 total
Full trace: |
| const disposals = await disposeWith({ | ||
| type: 'hook_dispose', | ||
| correlationId: 'hook_01JCHOOK', | ||
| token: 'order-42-approve', |
There was a problem hiding this comment.
AI: This test injects a token directly into the pending operation, but the terminal system-hook cleanup path in quickjs-runtime.ts (the synthesized hook_dispose around lines 2621-2625) does not copy p.token. As a result, completing a workflow with a durable, unaborted AbortController hook still reaches this entrypoint without a token and emits no eventData, unlike node:vm. Please include token: p.token in that synthesized operation and cover that producer path. A shared cross-runtime conformance harness can remain a follow-up; fixing this focused regression does not require that refactor.
There was a problem hiding this comment.
Confirmed and fixed in 3873b69b23. You are right about the mechanism and about the parity: I fixed the consumer and missed a producer.
Two paths build a hook_dispose. disposeHook in the VM builds it from the hook’s own closure and has always carried the token. The completion drain synthesizes a fresh object for a durable system hook the workflow never aborted, and dropped it:
toDispose.push({
type: "hook_dispose",
correlationId: p.correlationId,
token: p.token, // <- added
hasCreatedEvent: false,
});And node:vm does send a token in that same case, which I checked rather than assumed: workflow.ts:91-99 marks the live system hook disposed at completion and hands the same queue item to handleSuspension, which reaches disposeHook(queueItem) and its eventData: { token: queueItem.token }. So the asymmetry was real and specific to this path.
Covered at the producer rather than by injecting an op, since injecting one is what let this through in the first place. The new test in quickjs-runtime.test.ts runs a workflow that creates an AbortController, replays it with the hook durably created and its step completed so the drain actually runs, and asserts the synthesized operation carries the hook’s token:
× carries the system hook token into the completion-drain disposal
AssertionError: expected undefined to be 'abrt_01JGFJJZ00NJ87CBWD49MG5PQC'
That is the failure on the previous commit; it passes on this one. packages/core/src/runtime is green at 729.
Agreed on the conformance harness being the right long-term answer and out of scope here. Worth noting what would have caught this cheaply in the meantime: the two engines share no test that asserts they emit the same event data for the same workflow, and both of my tests are per-engine. If you want, I can open a follow-up issue describing the harness shape rather than leaving it in a review thread.
TooTallNate
left a comment
TooTallNate
left a comment
There was a problem hiding this comment.
AI: Request changes. The entrypoint now forwards a token when the pending operation contains one, but QuickJS terminal cleanup still synthesizes tokenless system-hook disposal operations, so parity with node:vm remains incomplete. The blocking producer-path issue is inline. A shared runtime conformance harness would be preferable long-term but is not required for this fix.
The entrypoint change covered the consumer and missed a producer. Two paths reach it with a `hook_dispose` operation: `disposeHook` in the VM, which builds the op from the hook's own closure and has always carried the token, and the completion drain, which synthesizes a fresh object for a durable system hook the workflow never aborted — and dropped it. So finishing a workflow holding a live AbortController still emitted a `hook_disposed` with no `eventData`, which is exactly the case node:vm sends a token for: its drain marks the queue item disposed and hands the same item to `handleSuspension`, token included. Covered at the producer rather than by injecting an op: the new test runs a workflow that creates an AbortController, replays it with the hook durably created and its step done so the drain actually runs, and asserts the synthesized operation carries the hook's token. It fails on the previous commit. Reported in review on #3773. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
(AI) The two failing jobs are Both lanes fail on The diff is also the wrong shape to cause it. Five files, all additive, all QuickJS-engine or its tests:
Not re-running: a lane that fails identically on main will fail again. What is green and relevant: Two things I have NOT attributed and am not claiming are fine — flagging them so nobody assumes I checked:
|
TooTallNate
left a comment
TooTallNate
left a comment
There was a problem hiding this comment.
AI: Approved. The terminal QuickJS system-hook producer now preserves p.token, and the new test exercises the actual completion-drain path that previously bypassed the entrypoint-only regression test. A shared node:vm/QuickJS conformance harness remains desirable as a non-blocking follow-up.
|
No backport to The change is confined to the QuickJS engine ( To override, re-run the Backport to stable workflow manually via |
3 participants
The two engines disagree about what a disposal says.
suspension-handler.ts(node:vm) has always sent the hook's token onhook_disposed:quickjs-entrypoint.tssent noeventDataat all — even though the pending operation already carries the token, and already uses it to order same-token hook operations so a dispose releases a token before a later hook's creation is validated against it.Why it matters
A world may key a hook's token claim separately from the hook itself, in which case retiring a hook means releasing both, and it needs to know which token this disposal is for. Told nothing, such a world has to look the token up before it can act — and the same workflow then does measurably different work depending on which VM ran it.
hook_disposed'seventData.tokenis optional in the schema, so neither engine is wrong on the wire; they are just inconsistent, which makes this the kind of thing that surfaces as a backend-shaped bug report rather than an engine one.world-vercelis the case in hand: it uses the token to release the hook and its token claim together.The change
One field, from the operation the VM already populates:
Omitted rather than sent as
undefinedwhen the operation carries none.PendingHookDispose.tokenis optional, and an explicitundefinedencodes differently across the JSON and CBOR wire formats — leaving the field off keeps this engine indistinguishable from a client too old to send one, which is a case a world already has to handle.Tests
packages/core/src/runtime/quickjs-hook-dispose-token.test.tsdrives the entrypoint over a singlehook_disposeoperation with the VM mocked, so what is under test is the request the entrypoint builds rather than the VM that produced the operation. Two cases: the token is carried, andeventDatais absent entirely when the operation has none.Verified the first case fails without the change:
packages/core/src/runtimeis green at 728 tests, andhookDisposeTestWorkflowalready covers disposal end to end on the QuickJS lanes.🤖 Generated with Claude Code