fix(core): preserve replay order for hook registration outcomes by gaojude · Pull Request #4215 · vercel/workflow

gaojude · 2026-09-16T22:49:03Z

Description

A workflow that concurrently awaits a sleep/hook registration and a read/save chain can replay a longer history with start taking the correlation ID already committed for save:

Replay divergence: step event step_created for <id> belongs to "save", but the current step consumer is "start"

hook_created and hook_conflict settled directly through promiseQueue. An earlier step result can still be parked behind a wait after that queue drains, allowing the registration acknowledgement to resume its branch first. The hasCreated/hasConflict fast paths have the same gap. This remains reproducible on main at 59a7c5bb, after #3139 and #3406.

Register hook outcomes with the existing delivery barriers, capture their predecessors when consuming the event, and settle off the serial queue. Late registration/conflict awaits share that delivery gate. The delivery runs even without an existing awaiter, so the armed barrier cannot wait indefinitely for workflow code to claim it.

How did you test your changes?

Added a synthetic regression using the real runWorkflow, replayWorkflow, and resumeWorkflow engines. It learns IDs from a shorter history and checks the extended history through suspension and completion, with cold/warm payload caches, both log-order-draws modes, registration/conflict outcomes, and buffered payloads left unread or claimed after registration.
Added six focused checks for already-consumed registration/conflict events, with and without an existing awaiter, including conflicting Run handles and legacy conflict rejections.
Restoring main's hook.ts while keeping these tests: 14 failed, 2 passed; the replay failures show the mismatch above. With the fix all 16 pass.
Full core suite (WORKFLOW_TARGET_WORLD=local vitest run packages/core/src packages/core/e2e/utils.test.ts): 117 files passed; 2,537 tests passed, 3 expected failures, 1 skipped.
Core build/typecheck, repository Biome check, changeset validation, and git diff --check pass. Biome reports existing warnings.

The regression needs no deployment or external workflow executions. Hosted/deployment E2E suites were not run.

PR Checklist - Required to merge

Patch changeset for @workflow/core created with pnpm changeset add
DCO sign-off included
Ping @vercel/workflow when ready for review (this PR is a draft)

Signed-off-by: Jude Gao <32973745+gaojude@users.noreply.github.com>

vercel · 2026-09-16T22:49:06Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
example-nextjs-workflow-turbopack	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
example-nextjs-workflow-webpack	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
example-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workbench-astro-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workbench-express-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workbench-fastify-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workbench-hono-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workbench-nestjs-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workbench-nitro-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workbench-nuxt-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workbench-python-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workbench-sveltekit-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workbench-tanstack-start-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workbench-vite-workflow	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workflow-docs	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workflow-swc-playground	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workflow-tarballs	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC
workflow-web	Ready	Preview, v0	Sep 16, 2026 10:53pm UTC

changeset-bot · 2026-09-16T22:49:07Z

🦋 Changeset detected

Latest commit: 27a7db1

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

This PR includes changesets to release 16 packages

Name	Type
@workflow/core	Patch
@workflow/builders	Patch
@workflow/cli	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/vitest	Patch
@workflow/web-shared	Patch
@workflow/web	Patch
workflow	Patch
@workflow/world-testing	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch
@workflow/nuxt	Patch

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

github-actions · 2026-09-16T22:49:18Z

🧪 E2E Test Results

✅ All tests passed

⚠️ Flaky E2E Tests (passed on retry)

These tests failed at least once and passed on a retry. A recurring entry here is a real race worth investigating.

applies prepareCall before streaming (sveltekit · vercel-prod / vercel / node / production)
plainModuleDoneHook resumed via plain API route (o2flow shape) (nextjs-webpack · local-dev / local / node / canary)
sleepWinsRaceWorkflow (vite · local-dev / local / node / stable)

🛠 Infra Events (absorbed by the harness)

Platform anomalies the e2e harness detected and worked around (e.g. a run the queue never picked up, replaced by a fresh run). Clustered timestamps indicate a backend blip; a steady drip indicates a platform issue worth escalating.

cold-start-warmup · suite warmup (tanstack-start) · at 22:54:37Z · abandoned wrun_01M2P6TXA9MZJPKPKDCP2T912C
run-pickup-stall · hookCleanupTestWorkflow - hook token reuse after workflow completion (nextjs-webpack) · at 23:02:04Z · abandoned wrun_01M2P78Y6NV42A5CYNECNBB11D

E2E Test Summary

Summary

	Passed	Skipped	Total
✅ ▲ Vercel Production	3662	685	4347
✅ 💻 Local Development	3998	510	4508
✅ 📦 Local Production	3998	510	4508
✅ 🐘 Local Postgres	3998	510	4508
✅ 🪟 Windows	320	2	322
✅ 🌐 Cross-language Conformance	68	74	142
✅ vercel-http-transport	823	143	966
✅ vercel-multi-region	27	0	27
✅ vercel-ws-transport	557	87	644
Total	17451	2521	19972

Details by Category

✅ ▲ Vercel Production

App	Passed	Skipped
✅ astro-node	133	28
✅ astro-quickjs	133	28
✅ example-node	133	28
✅ example-quickjs	133	28
✅ express-node	133	28
✅ express-quickjs	133	28
✅ fastify-node	133	28
✅ fastify-quickjs	133	28
✅ hono-node	133	28
✅ hono-quickjs	133	28
✅ nest-node	133	28
✅ nest-quickjs	133	28
✅ nextjs-turbopack-node	158	3
✅ nextjs-turbopack-quickjs	158	3
✅ nextjs-webpack-node	158	3
✅ nextjs-webpack-quickjs	158	3
✅ nitro-node	133	28
✅ nitro-quickjs	133	28
✅ nuxt-node	133	28
✅ nuxt-quickjs	133	28
✅ python-node	66	95
✅ sveltekit-node	152	9
✅ sveltekit-quickjs	152	9
✅ tanstack-start-node	133	28
✅ tanstack-start-quickjs	133	28
✅ vite-node	133	28
✅ vite-quickjs	133	28

✅ 💻 Local Development

App	Passed	Skipped
✅ astro-stable-node	134	27
✅ astro-stable-quickjs	134	27
✅ express-stable-node	134	27
✅ express-stable-quickjs	134	27
✅ fastify-stable-node	134	27
✅ fastify-stable-quickjs	134	27
✅ hono-stable-node	134	27
✅ hono-stable-quickjs	134	27
✅ nest-stable-node	134	27
✅ nest-stable-quickjs	134	27
✅ nextjs-turbopack-canary-node	160	1
✅ nextjs-turbopack-canary-quickjs	160	1
✅ nextjs-turbopack-stable-node	160	1
✅ nextjs-turbopack-stable-quickjs	160	1
✅ nextjs-webpack-canary-node	160	1
✅ nextjs-webpack-canary-quickjs	160	1
✅ nextjs-webpack-stable-node	160	1
✅ nextjs-webpack-stable-quickjs	160	1
✅ nitro-stable-node	134	27
✅ nitro-stable-quickjs	134	27
✅ nuxt-stable-node	134	27
✅ nuxt-stable-quickjs	134	27
✅ sveltekit-stable-node	153	8
✅ sveltekit-stable-quickjs	153	8
✅ tanstack-start-node	134	27
✅ tanstack-start-quickjs	134	27
✅ vite-stable-node	134	27
✅ vite-stable-quickjs	134	27

✅ 📦 Local Production

App	Passed	Skipped
✅ astro-stable-node	134	27
✅ astro-stable-quickjs	134	27
✅ express-stable-node	134	27
✅ express-stable-quickjs	134	27
✅ fastify-stable-node	134	27
✅ fastify-stable-quickjs	134	27
✅ hono-stable-node	134	27
✅ hono-stable-quickjs	134	27
✅ nest-stable-node	134	27
✅ nest-stable-quickjs	134	27
✅ nextjs-turbopack-canary-node	160	1
✅ nextjs-turbopack-canary-quickjs	160	1
✅ nextjs-turbopack-stable-node	160	1
✅ nextjs-turbopack-stable-quickjs	160	1
✅ nextjs-webpack-canary-node	160	1
✅ nextjs-webpack-canary-quickjs	160	1
✅ nextjs-webpack-stable-node	160	1
✅ nextjs-webpack-stable-quickjs	160	1
✅ nitro-stable-node	134	27
✅ nitro-stable-quickjs	134	27
✅ nuxt-stable-node	134	27
✅ nuxt-stable-quickjs	134	27
✅ sveltekit-stable-node	153	8
✅ sveltekit-stable-quickjs	153	8
✅ tanstack-start-node	134	27
✅ tanstack-start-quickjs	134	27
✅ vite-stable-node	134	27
✅ vite-stable-quickjs	134	27

✅ 🐘 Local Postgres

App	Passed	Skipped
✅ astro-stable-node	134	27
✅ astro-stable-quickjs	134	27
✅ express-stable-node	134	27
✅ express-stable-quickjs	134	27
✅ fastify-stable-node	134	27
✅ fastify-stable-quickjs	134	27
✅ hono-stable-node	134	27
✅ hono-stable-quickjs	134	27
✅ nest-stable-node	134	27
✅ nest-stable-quickjs	134	27
✅ nextjs-turbopack-canary-node	160	1
✅ nextjs-turbopack-canary-quickjs	160	1
✅ nextjs-turbopack-stable-node	160	1
✅ nextjs-turbopack-stable-quickjs	160	1
✅ nextjs-webpack-canary-node	160	1
✅ nextjs-webpack-canary-quickjs	160	1
✅ nextjs-webpack-stable-node	160	1
✅ nextjs-webpack-stable-quickjs	160	1
✅ nitro-stable-node	134	27
✅ nitro-stable-quickjs	134	27
✅ nuxt-stable-node	134	27
✅ nuxt-stable-quickjs	134	27
✅ sveltekit-stable-node	153	8
✅ sveltekit-stable-quickjs	153	8
✅ tanstack-start-node	134	27
✅ tanstack-start-quickjs	134	27
✅ vite-stable-node	134	27
✅ vite-stable-quickjs	134	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	Skipped
✅ example	133	28
✅ express	133	28
✅ hono	133	28
✅ nextjs-turbopack	158	3
✅ nitro	133	28
✅ vite	133	28

✅ vercel-multi-region

App	Passed	Failed	Skipped
✅ nextjs-turbopack	27	0	0

✅ vercel-ws-transport

App	Passed	Skipped
✅ example	133	28
✅ express	133	28
✅ nextjs-turbopack	158	3
✅ vite	133	28

📋 View full workflow run

github-actions · 2026-09-16T22:49:26Z

📊 Workflow Benchmarks

commit 27a7db1 · Wed, 16 Sep 2026 23:06:53 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric	Scenario	Best (ms)	P75 (ms)	P90 (ms)	P99 (ms)	Samples
TTFS	step	1487 (+640%) 🔻	1674 🔴 (+17%) 🔻	1698 🔴 (+7.9%)	1878 🔴 (+17%) 🔻	30
TTFS	stream	156 (-39%) 💚	1662 🔴 (+17%) 🔻	1693 🔴 (+9.3%)	1750 🔴 (+7.8%)	30
TTFS	hook + stream	1990 (+267%) 🔻	2071 🔴 (+8.9%)	2114 🔴 (+2.9%)	2713 🔴 (+14%)	30
Fan-out TTFS	Promise.all(100 steps)	490 (-1.2%)	798 (+10%)	798 (+0.8%)	856 (-52%) 💚	10
Fan-out TTLS	Promise.all(100 steps)	1990 (±0%)	2845 (+17%) 🔻	3468 (+40%) 🔻	7651 (+4.1%)	10
STSO	1020 steps (inline)	117 (+16%) 🔻	140 (-2.1%)	155 (-7.2%)	224 (-37%) 💚	1019
WO	1020 steps	141416 (-26%) 💚	141416 (-26%) 💚	141416 (-26%) 💚	141416 (-26%) 💚	1
CRTT	first chunk (pooled)	59 (-14%)	83 (-29%) 💚	102 (-27%) 💚	138 (-67%) 💚	28

Streams

Scenario	CRTT 1st	p75	p90	p99	CDV max	iters
paced control (100/s, 60B)	81.5 (-17%)	140 (-33%)	177 (-46%)	419 (-81%)	112 (-32%)	10
size sweep (100/s, 160B-12KB)	74.5 (-22%)	143 (-46%)	304 (-60%)	461 (-59%)	117 (-48%)	10
replay gateway-gpt-5.4-nano-2000t (1x)	75 (-37%)	117 (-57%)	140 (-65%)	233 (-62%)	176 (-66%)	3
replay eve-gpt-5.6-sol-2000t (1x)	71.5 (-74%)	134 (-36%)	191 (-38%)	504 (-17%)	438 (-20%)	2
replay eve-gpt-5.6-sol-2000t (2x)	78 (-16%)	206 (-55%)	284 (-50%)	4688 (+441%)	264 (-59%)	3

📈 STSO distribution vs main (inline / queue-hop histograms)

1020 steps (inline)

Cumulative STSO time: main 192073ms → this run 141113ms (Δ -50960ms, -27%)

    100-150 ms  ██████████████████████░┃  main 813  this 870   +57
    150-200 ms  ███┃                      main 162  this 130   -32
    200-250 ms  ┃                         main  22  this  13    -9
    250-300 ms  ┃                         main   9  this   2    -7
    300-350 ms  ┃                         main   2  this   2    +0
    350-400 ms  ┃                         main   2  this   0    -2
    400-450 ms  ┃                         main   1  this   0    -1
    500-550 ms  ┃                         main   1  this   2    +1
    750-800 ms  ┃                         main   1  this   0    -1
  4000-4050 ms  ┃                         main   1  this   0    -1
  4700-4750 ms  ┃                         main   1  this   0    -1
  4850-4900 ms  ┃                         main   1  this   0    -1
  7500-7550 ms  ┃                         main   1  this   0    -1
  7550-7600 ms  ┃                         main   1  this   0    -1
18750-18800 ms  ┃                         main   1  this   0    -1

📈 CRTT drill-down vs main (RTT distributions & profiles)

variant  RTT 1ms→5s+             avg         p50         p90           p99     n
control  ······▄█▁····  119.7 (-47%)  114 (-32%)  177 (-46%)    419 (-81%)  3000
sweep    ······▄█▁····  129.5 (-43%)  117 (-35%)  304 (-60%)    461 (-59%)  3000
gw 1x    ·····▁██▁····  104.9 (-49%)  101 (-43%)  140 (-65%)    233 (-62%)  5295
eve 1x   ·····▁▆█▁▁···  120.6 (-35%)  104 (-35%)  191 (-38%)    504 (-17%)  5186
eve 2x   ·····▁▂█▃▁·▁·  196.1 (-42%)  149 (-51%)  284 (-50%)  4688 (+441%)  7779

RTT over stream progress (avg per tenth of stream, bars scaled min→max):

control  ▇▆▆▄▃▄▁▅█▆  106–129ms
sweep    ▂▇▆▃▂█▆▁▄▅  111–149ms
gw 1x    █▇▅▆▃▁▃▃▄▇  96–115ms
eve 1x   ▁▆█▁▂▅▅▄▄▂  104–145ms
eve 2x   ▁▁▁▁▁▁▂▂▂█  131–548ms

RTT by chunk size (avg per log size bin, ~160B → ~12KB serialized, bars scaled min→max):

sweep  ▁▄▆█▇▁▁  128–131ms

Delivery jitter over stream progress (avg positive CDV per tenth of stream, bars scaled min→max):

control  ▄█▅▄▁▃▁▇▂▂  34–43ms
sweep    ▃█▆▁▃█▆▁▇▁  47–65ms
gw 1x    ▆█▅▂▆▃▅▃▁█  28–35ms
eve 1x   ▂█▆▁▇▁▇▃▆▅  20–28ms
eve 2x   ▂▂▁▁▂▂▁▁▂█  22–59ms

ℹ️ Metric definitions & methodology

_{Streams: 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). █ = main, ┃ = this run, ░ = fill.}

_{The collapsed CRTT drill-down: per-variant RTT histograms (fixed log bins, · = empty) and mean RTT/positive-CDV profile lines over stream progress and chunk size. Histograms, avgs, and profiles merge exactly across runs; p50–p99 are percentile-of-percentiles. Per-index rows live in the artifacts.}

_{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) · 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 eaf22f5946e7c61f3c65c7006d550df180cfabd4e706254a09f22aec0cfb420d · gateway-gpt-5.4-nano-2000t 6f24ac518b6b83ff1d0e85a5fe78230db192716d66a7fc6b2fe022752001d041}

_{🔴 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 = start() → first step body (includes dispatch + any cold start); Fan-out TTFS/TTLS = first/last step completion of one Promise.all from the same anchor (the gap is the runtime’s fan-out spread); STSO/WO between step bodies; CRTT inside the workflow (excludes the api.vercel.com read path).}

_{Cold starts stay in the numbers (real bursty-workload latency, inflates P75+); Best is the warm floor.}

github-actions · 2026-09-16T22:52:31Z

Sim World

Simulated world deterministic testing for races. Traces

🟠 world-sim scenario book — 1 fail of 41 total

fence=per-spec

scenario	outcome	events	virt	replay
✅ `smoke-no-steps`	completed	3	0ms	ok
✅ `smoke-one-step`	completed	6	0ms	ok
✅ `hook-at-step-started`	completed	12	0ms	ok
✅ `hook-at-step-completed`	completed	12	0ms	ok
✅ `hook-at-hook-created`	completed	12	0ms	ok
✅ `deadline-hook-wins`	completed	7	1.0h	ok
✅ `deadline-expires`	completed	7	1.0h	ok
✅ `long-sleep`	completed	11	30.0d	ok
✅ `hook-never-arrives`	stalled	3	0ms	skipped
✅ `step-retries-twice`	completed	10	2.0s	ok
✅ `parallel-steps`	completed	9	0ms	ok
✅ `hook-on-execution-state`	completed	12	0ms	ok
✅ `peek-hook-before-branch`	completed	12	0ms	ok
✅ `peek-hook-after-branch`	completed	12	0ms	ok
✅ `peek-hook-at-registration`	completed	12	0ms	ok
✅ `race-hook-before-probe`	completed	12	0ms	ok
✅ `race-hook-after-probe`	completed	12	0ms	ok
✅ `race-duplicate-delivery`	completed	13	0ms	ok
✅ `attr-hook-before-step`	completed	11	0ms	ok
✅ `attr-hook-after-step`	completed	11	0ms	ok
✅ `attr-from-step-body`	completed	13	0ms	ok
✅ `fork-hook-after-timeout`	completed	14	1.0m	ok
✅ `fork-hook-before-timeout`	completed	14	1.0m	ok
✅ `count-hook-after-timeout`	completed	17	1.0m	ok
✅ `count-hook-before-timeout`	completed	20	1.0m	ok
✅ `stale-read-step-count-fork`	completed	20	1.0m	ok
✅ `stale-read-equal-step-counts`	completed	14	1.0m	ok
✅ `step-vs-step-fork`	completed	12	0ms	ok
✅ `step-vs-step-fork-fenced`	completed	12	0ms	ok
✅ `fence-catches-benign-direction`	completed	12	5ms	ok
✅ `in-flight-before-decision`	completed	17	1.0m	ok
❌ `in-flight-before-decision-counted`	completed	17	1.0m	ok
✅ `in-flight-after-decision`	completed	19	2.0m	ok
✅ `stale-read-step-count-fork-fenced`	completed	20	1.0m	ok
✅ `fork-hook-wins`	completed	13	1.0m	ok
✅ `fork-timeout-wins`	completed	13	1.0m	ok
✅ `unclaimed-payload-under-fork`	completed	17	1.0m	ok
✅ `claimed-payload-under-fork`	completed	17	1.0m	ok
✅ `writers-independent-step-bodies`	completed	12	0ms	ok
✅ `writers-scripted-tempo`	completed	12	0ms	ok
✅ `cancel-mid-step`	cancelled	7	0ms	skipped

Full trace: world-sim.txt

github-actions · 2026-09-16T22:53:41Z

Framework	Flow route	Step reg.	Framework output
hono	250.9 KiB (±0)	93.2 KiB (±0)	1.89 MiB (+89 B)
nextjs-turbopack	257.3 KiB (±0)	426 B (±0)	900.4 KiB (+62 B)

About these numbers

Sizes are gzip; parentheses show the change against main.
Flow route and Step reg. gate this job, on raw bytes rather than the gzip shown, at max(2%, 50.0 KiB). Framework output is informational.

27a7db1 · run

Signed-off-by: Jude Gao <32973745+gaojude@users.noreply.github.com> Signed-off-by: Jude Gao <jude.gao@vercel.com>

github-actions · 2026-09-17T15:26:25Z

Backport PR opened against stable: #4220. Merge conflicts were resolved by AI — please review carefully. (backport job run)

…edAt hook_created and hook_conflict now advance the clock through the barrier release that main already hands them over on, instead of the explicit advanceClock calls this branch added before that barrier existed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

@VaguelySerious

* [core] Anchor the replay clock to deliveries, not consumption The VM's Date.now() advanced in EventsConsumer.onConsumedEvent, i.e. when the walk read an event. The walk runs ahead of delivery: within one drain window it consumes every event whose consumer exists, so a hook_received for a hook the workflow has not read, or a sibling step's later result, was consumed while an earlier delivery still sat on its barrier, and its timestamp leaked into that delivery's cascade. Date.now() at a body position then depended on how much log the replay held: the writing execution saw the heartbeat's time, a later replay holding one more payload saw the payload's. A workflow whose control flow reads the clock (an idle loop budgeted by Date.now(), a deadline) drew different ordinals in different replays and died CORRUPTED_EVENT_LOG. This is the production wake-loop family of the 2026-08-31 beta.46 spike: step and heartbeat wait bound to one ordinal by the same invocation a second apart, with the wait's resumeAt computed from the earlier step's completion time. The clock now advances in registerDeliveryBarrier's markDelivered, with the delivered event's createdAt, for step results, hook payloads, wait completions and aborts. Deliveries reach the workflow in log order, so the clock a cascade observes is a function of the log prefix. The long-parked it.fails "should maintain determinism of Date across executions" (a race of two sleeps) passes and is flipped to it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Apply suggestion from @VaguelySerious Signed-off-by: Peter Wielander <mittgfu@gmail.com> * docs: say when the workflow clock advances Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Address review: registration outcomes advance the clock; deliveredAt required; more cases hook_created and hook_conflict settle awaiters the workflow is blocked on, so they are deliveries and now advance the clock in their settlement slots (they registered no barrier on this branch and had stopped moving it, a regression against main). registerDeliveryBarrier requires deliveredAt so a new delivery site cannot forget the clock, with one hoisted deliver() closure behind both handle shapes. Tests cover the buffered-payload claim (a delivery carrying an older time than the clock), both registration outcomes, and aborts. Comments that described the consumption-anchored clock are updated, and the QuickJS note now says that engine still advances per event and why that is prefix-stable there. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Rebase onto main: the registration barrier from #4215 carries deliveredAt hook_created and hook_conflict now advance the clock through the barrier release that main already hands them over on, instead of the explicit advanceClock calls this branch added before that barrier existed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Apply suggestion from @VaguelySerious Signed-off-by: Peter Wielander <mittgfu@gmail.com> --------- Signed-off-by: Peter Wielander <mittgfu@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

@VaguelySerious

* [core] Anchor the replay clock to deliveries, not consumption The VM's Date.now() advanced in EventsConsumer.onConsumedEvent, i.e. when the walk read an event. The walk runs ahead of delivery: within one drain window it consumes every event whose consumer exists, so a hook_received for a hook the workflow has not read, or a sibling step's later result, was consumed while an earlier delivery still sat on its barrier, and its timestamp leaked into that delivery's cascade. Date.now() at a body position then depended on how much log the replay held: the writing execution saw the heartbeat's time, a later replay holding one more payload saw the payload's. A workflow whose control flow reads the clock (an idle loop budgeted by Date.now(), a deadline) drew different ordinals in different replays and died CORRUPTED_EVENT_LOG. This is the production wake-loop family of the 2026-08-31 beta.46 spike: step and heartbeat wait bound to one ordinal by the same invocation a second apart, with the wait's resumeAt computed from the earlier step's completion time. The clock now advances in registerDeliveryBarrier's markDelivered, with the delivered event's createdAt, for step results, hook payloads, wait completions and aborts. Deliveries reach the workflow in log order, so the clock a cascade observes is a function of the log prefix. The long-parked it.fails "should maintain determinism of Date across executions" (a race of two sleeps) passes and is flipped to it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Apply suggestion from @VaguelySerious Signed-off-by: Peter Wielander <mittgfu@gmail.com> * docs: say when the workflow clock advances Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Address review: registration outcomes advance the clock; deliveredAt required; more cases hook_created and hook_conflict settle awaiters the workflow is blocked on, so they are deliveries and now advance the clock in their settlement slots (they registered no barrier on this branch and had stopped moving it, a regression against main). registerDeliveryBarrier requires deliveredAt so a new delivery site cannot forget the clock, with one hoisted deliver() closure behind both handle shapes. Tests cover the buffered-payload claim (a delivery carrying an older time than the clock), both registration outcomes, and aborts. Comments that described the consumption-anchored clock are updated, and the QuickJS note now says that engine still advances per event and why that is prefix-stable there. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Rebase onto main: the registration barrier from #4215 carries deliveredAt hook_created and hook_conflict now advance the clock through the barrier release that main already hands them over on, instead of the explicit advanceClock calls this branch added before that barrier existed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * Apply suggestion from @VaguelySerious Signed-off-by: Peter Wielander <mittgfu@gmail.com> --------- Signed-off-by: Peter Wielander <mittgfu@gmail.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Peter Wielander <mittgfu@gmail.com>

…n outcomes (#4220) Automated backport of #4215 to `stable` ([backport job run](https://github.com/vercel/workflow/actions/runs/35239340733)). Signed-off-by: Jude Gao <jude.gao@vercel.com> Co-authored-by: Peter Wielander <mittgfu@gmail.com> Co-authored-by: Jude Gao <jude.gao@vercel.com>

) Closes #4770. ### Problem When `setAttributes()` resolves, its `attr_set` acknowledgement settled straight off `promiseQueue` without registering a delivery barrier. Every other delivery that resumes a branch (step results, waits, hook payloads and, since #4215, hook registration outcomes) registers one and waits for earlier deliveries. A branch awaiting `setAttributes()` could therefore resume ahead of a sibling's step result that comes earlier in the log, and draw that sibling's next correlation ID. Depending on what the sibling draws next, the run either fails with `REPLAY_DIVERGENCE`, or both branches call the same step and silently receive each other's results. ### Fix - Add an `attribute` `DeliveryKind`. It defers behind every earlier kind, and every kind defers behind an earlier `attribute`. Like a step, it skips unclaimed buffered hook payloads, because resolving it never depends on a hook read. - `attribute-dispatcher.ts` registers the barrier and captures `awaitEarlierDeliveries` when it consumes the event, then resolves from a continuation that is detached from the queue tail, following the same pattern as `sleep.ts`. - `setAttributes()` resolution still does not move the workflow clock. `registerDeliveryBarrier` now accepts `deliveredAt: null` to opt out explicitly. - The QuickJS runtime needs no change. It delivers events strictly in log order and drains jobs after each one. Co-authored-by: Peter Wielander <mittgfu@gmail.com>

fix(core): preserve replay order for hook registration outcomes

27a7db1

Signed-off-by: Jude Gao <32973745+gaojude@users.noreply.github.com>

vercel Bot deployed to Preview – workbench-python-workflow September 16, 2026 22:49

View deployment

vercel Bot deployed to Preview – workflow-web September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – workbench-nitro-workflow September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – workbench-fastify-workflow September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – workbench-express-workflow September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – workbench-nestjs-workflow September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – workbench-nuxt-workflow September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – workbench-hono-workflow September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – example-workflow September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – workflow-tarballs September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – workbench-astro-workflow September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – example-nextjs-workflow-turbopack September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – workbench-sveltekit-workflow September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – workbench-vite-workflow September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – workbench-tanstack-start-workflow September 16, 2026 22:50

View deployment

vercel Bot deployed to Preview – example-nextjs-workflow-webpack September 16, 2026 22:51

View deployment

vercel Bot deployed to Preview – workflow-docs September 16, 2026 22:51

View deployment

vercel Bot deployed to Preview – workflow-swc-playground September 16, 2026 22:53

View deployment

alangenfeld approved these changes Sep 17, 2026

View reviewed changes

alangenfeld marked this pull request as ready for review September 17, 2026 15:17

alangenfeld requested a review from a team as a code owner September 17, 2026 15:17

alangenfeld merged commit f75b184 into main Sep 17, 2026
186 checks passed

alangenfeld deleted the codex/fix-hook-registration-replay-order branch September 17, 2026 15:18

github-actions Bot mentioned this pull request Sep 17, 2026

Version Packages (beta) #4191

Merged

github-actions Bot added a commit that referenced this pull request Sep 17, 2026

fix(core): preserve replay order for hook registration outcomes (#4215)

4a8c0fa

Signed-off-by: Jude Gao <32973745+gaojude@users.noreply.github.com> Signed-off-by: Jude Gao <jude.gao@vercel.com>

github-actions Bot mentioned this pull request Sep 17, 2026

Backport #4215: fix(core): preserve replay order for hook registration outcomes #4220

Merged

alangenfeld mentioned this pull request Sep 17, 2026

test(core): cover hook registration replay ordering #4201

Merged

This was referenced Sep 17, 2026

Version Packages ben-vargas/workflow#104

Closed

Version Packages (beta) Jokacar10/jkworkflow#548

Open

VaguelySerious mentioned this pull request Sep 17, 2026

[core] Anchor the replay clock to deliveries, not consumption #4213

Merged

This was referenced Sep 18, 2026

Version Packages Thegreatsura/workflow#1

Open

Version Packages (beta) erickirt/workflow#523

Open

github-actions Bot mentioned this pull request Sep 21, 2026

Backport #4213: [core] Anchor the replay clock to deliveries, not consumption #4274

Merged

github-actions Bot mentioned this pull request Oct 2, 2026

Version Packages #4590

Merged

mick340 mentioned this pull request Oct 8, 2026

[core] setAttributes() resolution bypasses the delivery barriers, so a branch awaiting it can resume out of log order and draw another branch's correlation id (replay divergence, or step results delivered to the wrong branch) #4770

Closed

pranaygp mentioned this pull request Oct 13, 2026

[core] Fix setAttributes() resolution bypassing delivery barriers #4861

Merged

Navigation Menu

Repository navigation

fix(core): preserve replay order for hook registration outcomes - #4215

fix(core): preserve replay order for hook registration outcomes#4215
alangenfeld merged 1 commit into
mainfrom
codex/fix-hook-registration-replay-order

gaojude commented Sep 16, 2026

Uh oh!

vercel Bot commented Sep 16, 2026 •

edited

Loading

Uh oh!

changeset-bot Bot commented Sep 16, 2026

Uh oh!

github-actions Bot commented Sep 16, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 16, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Sep 16, 2026

Uh oh!

github-actions Bot commented Sep 16, 2026

Uh oh!

Uh oh!

github-actions Bot commented Sep 17, 2026

Uh oh!

This branch was successfully deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

gaojude commented Sep 16, 2026

Description

How did you test your changes?

PR Checklist - Required to merge

Uh oh!

vercel Bot commented Sep 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

changeset-bot Bot commented Sep 16, 2026

🦋 Changeset detected

Uh oh!

github-actions Bot commented Sep 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🧪 E2E Test Results

⚠️ Flaky E2E Tests (passed on retry)

🛠 Infra Events (absorbed by the harness)

E2E Test Summary

Uh oh!

github-actions Bot commented Sep 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📊 Workflow Benchmarks

Uh oh!

github-actions Bot commented Sep 16, 2026

Sim World

Uh oh!

github-actions Bot commented Sep 16, 2026

Uh oh!

Uh oh!

github-actions Bot commented Sep 17, 2026

Uh oh!

This branch was successfully deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

vercel Bot commented Sep 16, 2026 •

edited

Loading

github-actions Bot commented Sep 16, 2026 •

edited

Loading

github-actions Bot commented Sep 16, 2026 •

edited

Loading