[world] Make the sealed log opt-in instead of default-on by VaguelySerious · Pull Request #3735 · vercel/workflow

VaguelySerious · 2026-08-21T23:19:29Z

Summary

default WORKFLOW_SEALED_LOG to off, so new runs are stamped at the slot-identity spec version rather than the sealed log (spec 7)
WORKFLOW_SEALED_LOG=1 opts in
reading is untouched: SPEC_VERSION_MAX_SUPPORTED stays 7 and the runtime still floors at slot identity
floor the world-testing stamped-version assertion at mintedSpecVersion() rather than SPEC_VERSION_CURRENT

Why

Main's E2E has been red continuously since #3634 landed. Two unmet preconditions for stamping spec 7 on every new run:

1. The Python runtime cannot read a sealed log

It validates specVersion <= 6 and rejects a spec-7 run_started outright:

1 validation error for RunStartedEvent
specVersion
  Input should be less than or equal to 6 [type=less_than_equal, input_value=7, input_type=int]

Every run it serves is unrunnable, which is why E2E Python Conformance and E2E Vercel Prod Tests (python - node) fail. The flag's own docs already say to leave it off where a runtime that pins its own spec range has not caught up; nothing was enforcing it.

2. A truncated sealed-log read makes a completed step look in-flight, and inline ownership then waits out a full 860s lease

This one is a composition bug between two individually-sound features.

Spec 7 assigns a log position before the write commits, so a fan-out nearly always has a position whose writer is still in flight. events.ts says so directly:

That proof does NOT hold on a sealed-log run: this page came from the densifying read, which legally cuts itself short below a position whose writer is still in flight, and under fanout there is nearly always such a position.

The densifying read truncates below that hole, and a truncated page comes back empty with hasMore: false. So a resume replay can read a log that stops below the step_completed events — the completed steps still look pending. backfillSealedLogHoles already documents the resulting wedge:

A fanout whose writer died mid-allocation delivers its remaining resumes within milliseconds; every one of those reads lands inside the young window and is told the log ends at the hole, the replay sees no completions and suspends, and the deliveries are then exhausted with the hole still open — a run wedged on a position nobody will ever fill.

What makes this a timed stall rather than a permanent wedge is inline step ownership (#2780). Those pending steps still carry an ownerMessageId on their latest step_started with no step_retrying, so isStepOwnershipActive is true and the lease has time left. The dispatch decision table then deliberately does not re-dispatch, because dispatching would double-execute a step that looks like it is still running:

instead of enqueueing the step. The owning invocation is (likely) still running the body; an immediate step message would bare-start the running step and execute it a second time (workflow#2780).

It arms a delayed run continuation at lastStartedAt + INLINE_OWNERSHIP_LEASE_SECONDS instead. That constant is 860. When the backstop fires the hole is long sealed, the log reads dense, and the run finishes in ~2s.

The data matches the constant, measured from the anchoring step_started on the e2e team, 2026-08-21 20:00-23:30 UTC:

preceding event	n	median	stddev
`step_completed`	330	861.31s	0.61s
`step_failed`	53	861.09s	0.47s

Sub-second variance over 383 samples: this is the lease, not queue jitter. (A second, noisier family sits at ~1086s after a step_started, stddev 56s — the owning message's redelivery re-stamping a fresh ownership epoch.)

Spec 6 cannot produce it: positions are allocated by the write that occupies them, so there is no hole, no truncation, and the replay always sees the completions. Same backend, same hour, spec-6 runs coming from PR branches whose base predates #3634:

specVersion	runs	stalled >120s	rate
7	28,500	380	1.333%
6	18,819	8	0.043%

A representative run (abortAnyInStepWorkflow, two parallel steps completing 168ms apart):

22:38:50.255  step_started    stepCombiningSignals  ┐ one invocation,
22:38:50.257  step_started    abortFromStep         ┘ inline-owned
22:38:51.379  hook_received
22:38:51.404  step_completed  stepCombiningSignals
22:38:51.572  step_completed  abortFromStep
      ... 859s, no events, no /flow invocations on the deployment ...
22:53:10.816  wait_created    resumeAt=22:38:51.672   <- step_started + 860.56s
22:53:12.609  run_completed

At a 60s e2e test timeout this surfaces as a diffuse spread of unrelated failures across nearly every framework lane.

Scope

This is the kill switch the flag was built for, not a fix for the composition. It buys back a green main and unblocks the Python lanes.

The actual fix is upstream of the flag and worth doing separately. Two candidates, and the first looks right: a truncated read must not feed the ownership decision. Truncation means "the log might not end here", so concluding a step is still pending from a page that admits it cut itself short is unsound — that path should re-read or re-drive rather than arm an 860s backstop. Relatedly, sealing a hole currently repairs the log but nothing re-drives the runs whose readers were truncated by it; a seal probably owes a resume.

Note this is a separate cause from #3709. That addresses run-status long-poll pool starvation after #3570, which is why main went red on 2026-08-20; these stalls begin 2026-08-21 ~20:00 UTC when #3634 landed. Both are needed for a green main.

Compatibility

Runs created while the flag was on keep working. Verified across two Worlds over one storage directory, writer opted in and reader on the new default:

writer World stamps       = 7
run created at            = 7
reader World stamps       = 6
run read back at          = 7
events readable           = 2 (run_created, run_started)
requiresNewerWorld        = false
advanced under new default= completed (specVersion 7)

assertWorldSupportsRuntimeProtocol accepts [6, 7], so the World this now selects is admitted; that floor was put there for exactly this rollback.

Test plan

pnpm --filter @workflow/world test (160 passed)
pnpm --filter @workflow/world-local test (557 passed)
pnpm --filter @workflow/world-vercel test (548 passed)
pnpm --filter @workflow/core test (104 files passed, 1 skipped)
vitest run packages/world-testing/test/embedded.test.ts (13 passed, incl. numbers events by position)
turbo run typecheck --filter=@workflow/world --filter=@workflow/core
biome check on the changed files
ad-hoc: mintedSpecVersion across unset/""/0/false/1/true/malformed, and the cross-flag readback above

🤖 Generated with Claude Code

Stamping spec 7 on every new run has two unmet preconditions. The Python runtime validates `specVersion <= 6` and rejects a spec-7 `run_started` outright, so every run it serves is unrunnable. The docs for the flag already say to leave it off where a runtime pinning its own spec range has not caught up; nothing was enforcing that. Pre-assigned positions are also stranding runs. A spec-7 run stalls between a step outcome and the resume that should follow it, and only the queue's own redelivery moves it on ~860s later (~1086s for a step dispatch). Measured on the e2e team over 2026-08-21 20:00-23:00 UTC, against the same backend in the same window: spec 7 stalled 380/28500 runs (1.33%) versus spec 6 at 8/18819 (0.04%). Reading is unchanged: SPEC_VERSION_MAX_SUPPORTED stays 7 and the runtime still floors at slot identity, so runs created while the flag was on stay readable and can still be advanced. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

changeset-bot · 2026-08-21T23:19:33Z

🦋 Changeset detected

Latest commit: 862f04e

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

This PR includes changesets to release 20 packages

Name	Type
@workflow/world	Patch
@workflow/world-vercel	Patch
@workflow/world-local	Patch
@workflow/world-postgres	Patch
@workflow/core	Patch
@workflow/cli	Patch
@workflow/vitest	Patch
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/world-testing	Patch
@workflow/builders	Patch
@workflow/next	Patch
@workflow/nitro	Patch
workflow	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

vercel · 2026-08-21T23:19:37Z

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

Project	Deployment	Actions	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, v0	Aug 21, 2026 11:34pm
example-nextjs-workflow-webpack	Ready	Preview, v0	Aug 21, 2026 11:34pm
example-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workbench-astro-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workbench-express-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workbench-fastify-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workbench-hono-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workbench-nestjs-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workbench-nitro-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workbench-nuxt-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workbench-python-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workbench-sveltekit-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workbench-tanstack-start-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workbench-vite-workflow	Ready	Preview, v0	Aug 21, 2026 11:34pm
workflow-swc-playground	Ready	Preview, v0	Aug 21, 2026 11:34pm
workflow-tarballs	Ready	Preview, v0	Aug 21, 2026 11:34pm
workflow-web	Ready	Preview, v0	Aug 21, 2026 11:34pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
workflow-docs	Skipped	v0	Aug 21, 2026 11:34pm

github-actions · 2026-08-21T23:19:46Z

🧪 E2E Test Results

❌ Some tests failed

❌ Failed E2E Tests

▲ Vercel Production (1 failed)

nextjs-webpack-quickjs (1 failed):

outputStreamWorkflow - getTailIndex and getChunks getChunks returns same content as reading the stream

⚠️ 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.

19 flaky tests

abortAnyInStepWorkflow: AbortSignal.any inside a step composes deserialized signals (sveltekit)
abortHookOrderingWorkflow [hook-first-hook-first]: hook.then → addEventListener → resumeHook → abort() (vite)
abortHookOrderingWorkflow [listener-first-hook-first]: addEventListener → hook.then → resumeHook → abort() (nest)
abortThrowIfAbortedWorkflow: throwIfAborted causes FatalError, no retries (nest)
abortThrowIfAbortedWorkflow: throwIfAborted causes FatalError, no retries (sveltekit)
addTenWorkflow (nitro)
cancelRun via CLI - cancelling a running workflow (nextjs-turbopack)
cancelRun via CLI - cancelling a running workflow (sveltekit)
concurrent hook token conflict - two workflows cannot use the same hook token simultaneously (nextjs-webpack)
distributedAbortController - TTL expiration triggers signal (hono)
getTailIndex returns correct index after stream completes (express)
getTailIndex returns correct index after stream completes (nest)
getTailIndex returns correct index after stream completes (sveltekit)
no startIndex (reads all chunks) (astro)
outputStreamInsideStepWorkflow - getWritable() called inside step functions (nuxt)
outputStreamInsideStepWorkflow - getWritable() called inside step functions (tanstack-start)
regular Error retries until success (astro)
sleepWinsRaceWorkflow (astro)
sleepWinsRaceWorkflow (tanstack-start)

🛠 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 23:34:49Z · abandoned wrun_01M0KASVA7EE4P9NPEWY71NBP2
run-pickup-stall · 'hookGetConflictWithPriorStepWorkflow' - hook.getConflict() does not block step execution (nextjs-webpack) · at 23:38:56Z · abandoned wrun_01M0KB1RQWRQ62FPRWSVAHH2EF
run-pickup-stall · 'hookGetConflictWithParallelStepWorkfl…' - hook.getConflict() does not block step execution (nextjs-webpack) · at 23:38:56Z · abandoned wrun_01M0KB1RVYZHER39BC2H2BCPBF
run-pickup-stall · hookGetConflictThenStepParallelWorkflow - hook.getConflict() continuation step runs alongside other steps (nextjs-webpack) · at 23:38:57Z · abandoned wrun_01M0KB1S4J2AMZVMQM1ZGAGX83

E2E Test Summary

Summary

	Passed	Failed	Skipped	Total
❌ ▲ Vercel Production	3577	1	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	9	0	132	141
✅ vercel-multi-region	27	0	0	27
Total	15699	1	2548	18248

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	156	1	3
✅ nitro-node	132	0	28
✅ nitro-quickjs	132	0	28
✅ nuxt-node	132	0	28
✅ nuxt-quickjs	132	0	28
✅ python-node	8	0	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	Skipped
✅ astro-stable-node	134	26
✅ astro-stable-quickjs	134	26
✅ express-stable-node	134	26
✅ express-stable-quickjs	134	26
✅ fastify-stable-node	134	26
✅ fastify-stable-quickjs	134	26
✅ hono-stable-node	134	26
✅ hono-stable-quickjs	134	26
✅ nest-stable-node	134	26
✅ nest-stable-quickjs	134	26
✅ nextjs-turbopack-canary-node	141	19
✅ nextjs-turbopack-canary-quickjs	141	19
✅ nextjs-turbopack-stable-node	160	0
✅ nextjs-turbopack-stable-quickjs	160	0
✅ nextjs-webpack-canary-node	141	19
✅ nextjs-webpack-canary-quickjs	141	19
✅ nextjs-webpack-stable-node	160	0
✅ nextjs-webpack-stable-quickjs	160	0
✅ nitro-stable-node	134	26
✅ nitro-stable-quickjs	134	26
✅ nuxt-stable-node	134	26
✅ nuxt-stable-quickjs	134	26
✅ sveltekit-stable-node	153	7
✅ sveltekit-stable-quickjs	153	7
✅ tanstack-start-node	134	26
✅ tanstack-start-quickjs	134	26
✅ vite-stable-node	134	26
✅ vite-stable-quickjs	134	26

✅ 📦 Local Production

App	Passed	Skipped
✅ astro-stable-node	134	26
✅ astro-stable-quickjs	134	26
✅ express-stable-node	134	26
✅ express-stable-quickjs	134	26
✅ fastify-stable-node	134	26
✅ fastify-stable-quickjs	134	26
✅ hono-stable-node	134	26
✅ hono-stable-quickjs	134	26
✅ nest-stable-node	134	26
✅ nest-stable-quickjs	134	26
✅ nextjs-turbopack-canary-node	141	19
✅ nextjs-turbopack-canary-quickjs	141	19
✅ nextjs-turbopack-stable-node	160	0
✅ nextjs-turbopack-stable-quickjs	160	0
✅ nextjs-webpack-canary-node	141	19
✅ nextjs-webpack-canary-quickjs	141	19
✅ nextjs-webpack-stable-node	160	0
✅ nextjs-webpack-stable-quickjs	160	0
✅ nitro-stable-node	134	26
✅ nitro-stable-quickjs	134	26
✅ nuxt-stable-node	134	26
✅ nuxt-stable-quickjs	134	26
✅ sveltekit-stable-node	153	7
✅ sveltekit-stable-quickjs	153	7
✅ tanstack-start-node	134	26
✅ tanstack-start-quickjs	134	26
✅ vite-stable-node	134	26
✅ vite-stable-quickjs	134	26

✅ 🐘 Local Postgres

App	Passed	Skipped
✅ astro-stable-node	134	26
✅ astro-stable-quickjs	134	26
✅ express-stable-node	134	26
✅ express-stable-quickjs	134	26
✅ fastify-stable-node	134	26
✅ fastify-stable-quickjs	134	26
✅ hono-stable-node	134	26
✅ hono-stable-quickjs	134	26
✅ nest-stable-node	134	26
✅ nest-stable-quickjs	134	26
✅ nextjs-turbopack-canary-node	141	19
✅ nextjs-turbopack-canary-quickjs	141	19
✅ nextjs-turbopack-stable-node	160	0
✅ nextjs-turbopack-stable-quickjs	160	0
✅ nextjs-webpack-canary-node	141	19
✅ nextjs-webpack-canary-quickjs	141	19
✅ nextjs-webpack-stable-node	160	0
✅ nextjs-webpack-stable-quickjs	160	0
✅ nitro-stable-node	134	26
✅ nitro-stable-quickjs	134	26
✅ nuxt-stable-node	134	26
✅ nuxt-stable-quickjs	134	26
✅ sveltekit-stable-node	153	7
✅ sveltekit-stable-quickjs	153	7
✅ tanstack-start-node	134	26
✅ tanstack-start-quickjs	134	26
✅ vite-stable-node	134	26
✅ vite-stable-quickjs	134	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	9	0	132

✅ vercel-multi-region

App	Passed	Failed	Skipped
✅ nextjs-turbopack	27	0	0

📋 View full workflow run

github-actions · 2026-08-21T23:19:50Z

📊 Workflow Benchmarks

commit 862f04e · Fri, 21 Aug 2026 23:49:46 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric	Scenario	Best (ms)	P75 (ms)	P90 (ms)	P99 (ms)	Samples
TTFS	step	1270 (+38%) 🔻	1420 🔴 (+39%) 🔻	1491 🔴 (+43%) 🔻	1591 🔴 (+45%) 🔻	30
TTFS	stream	463 (+70%) 🔻	1393 🔴 (+33%) 🔻	1409 🔴 (+30%) 🔻	1473 🔴 (+28%) 🔻	30
TTFS	hook + stream	660 (+23%) 🔻	1682 🔴 (+25%) 🔻	1729 🔴 (+20%) 🔻	1918 🔴 (+24%) 🔻	30
Fan-out TTFS	Promise.all(100 steps)	483 (-10%)	874 (-44%) 💚	1904 (+20%) 🔻	2013 (+25%) 🔻	10
Fan-out TTLS	Promise.all(100 steps)	4576 (+202%) 🔻	6658 (-5.7%)	7411 (-7.9%)	7512 (-23%) 💚	10
STSO	1020 steps (inline)	143 (+5.1%)	215 (+11%)	242 (+5.2%)	348 (-4.4%)	1019
WO	1020 steps	212130 (+12%)	212130 (+12%)	212130 (+12%)	212130 (+12%)	1
CRTT	first chunk (pooled)	85 (+3.7%)	130 (+10%)	148 (-22%) 💚	206 (-49%) 💚	28

Streams

Scenario	CRTT 1st	p75	p90	p99	CDV max	iters
paced control (100/s, 60B)	105 (-3%)	120 (-15%)	194 (-10%)	378 (-58%)	131 (-19%)	10
size sweep (100/s, 160B-12KB)	98.5 (-4%)	123 (-10%)	202 (-11%)	619 (+36%)	142 (-11%)	10
replay gateway-gpt-5.4-nano-2000t (1x)	126 (+12%)	114 (-33%)	155 (-57%)	563 (-23%)	224 (-62%)	3
replay eve-gpt-5.6-sol-2000t (1x)	151 (+4%)	117 (-16%)	175 (-5%)	666 (-8%)	460 (-19%)	2
replay eve-gpt-5.6-sol-2000t (2x)	114 (-10%)	146 (-33%)	207 (-38%)	373 (-50%)	202 (-34%)	3

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

1020 steps (inline)

Cumulative STSO time: main 188787ms → this run 211947ms (Δ +23160ms, +12%)

100-150 ms  ┃█                        main  69  this   3   -66
150-200 ms  ████████████████┃███████  main 748  this 522  -226
200-250 ms  █████░░░░░░░┃             main 141  this 412  +271
250-300 ms  █┃                        main  40  this  54   +14
300-350 ms  ┃                         main   7  this  18   +11
350-400 ms  ┃                         main   5  this   6    +1
400-450 ms  ┃                         main   3  this   1    -2
450-500 ms  ┃                         main   2  this   2    +0
550-600 ms  ┃                         main   1  this   0    -1
600-650 ms  ┃                         main   0  this   1    +1
650-700 ms  ┃                         main   1  this   0    -1
700-750 ms  ┃                         main   1  this   0    -1
850-900 ms  ┃                         main   1  this   0    -1

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

variant  RTT 1ms→5s+             avg         p50         p90         p99     n
control  ······██▁····  106.8 (-11%)    99 (+1%)  194 (-10%)  378 (-58%)  3000
sweep    ·····▁█▇▁▁···  108.7 (-10%)    97 (-7%)  202 (-11%)  619 (+36%)  3000
gw 1x    ·····▁█▅▁▁···  102.4 (-33%)   94 (-18%)  155 (-57%)  563 (-23%)  5295
eve 1x   ·····▁█▅▁▁···   113.6 (-9%)   89 (-17%)   175 (-5%)   666 (-8%)  5186
eve 2x   ·····▁▅█▂····  123.5 (-27%)  110 (-18%)  207 (-38%)  373 (-50%)  7779

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

control  █▆▃▅▅▃▂▁▂▂  95–126ms
sweep    ▁▂▄▂▂▅█▃▁▂  97–137ms
gw 1x    ▄▃▅▂▂▁▂█▇▂  90–124ms
eve 1x   ▂▃▁▂▁▃█▂▂▁  85–209ms
eve 2x   ▂▂▃▂▁▄▅█▃▁  100–180ms

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

sweep  ██▇▄▃▁▂  107–111ms

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

control  ▆▆▄██▃▃▃▄▁  27–37ms
sweep    ▁▆▇▅▆██▂▃▅  32–50ms
gw 1x    ▅▃█▁▄▂▄█▂▃  25–35ms
eve 1x   ▃▇▁▃▄▃█▁▃▂  18–29ms
eve 2x   ▄▂▃▁▅█▃▆▂▅  20–23ms

ℹ️ 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-08-21T23:23:23Z

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

The conformance suite pinned a run's stamped specVersion to SPEC_VERSION_CURRENT. What a World is told to stamp is mintedSpecVersion(), and the two differ whenever a version is readable before it is mintable — the normal mid-bump state, not a conformance defect. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

github-actions · 2026-08-21T23:33:09Z

No backport to stable for b2cac62 (AI decision).

This commit flips the WORKFLOW_SEALED_LOG default for the sealed-log spec version (spec 7), which does not exist on stable: git show origin/stable:packages/world/src/spec-version.ts caps at SPEC_VERSION_CURRENT = 3 with no mintedSpecVersion or SEALED_LOG_ENV_VAR, and packages/world-testing/src/event-ids.mts plus the docs/content/.../v5/ pages it touches are absent there. It is a mitigation for a regression introduced only on main (#3634), so there is nothing on the maintenance line for it to fix.

To override, re-run the Backport to stable workflow manually via workflow_dispatch and paste this commit SHA into the ref input:

b2cac623d33685e84090abc391178219f4edc960

* Revert "[world] Make the sealed log opt-in instead of default-on (#3735)" Reverts b2cac62. New runs are stamped at spec 7 again, now that a read which cannot see past an unfilled position waits for it instead of reporting a log that ends there (workflow-server: derive the in-request seal poll budget from the staleness bound). Two things are kept from #3735 rather than reverted: - the world-testing conformance floor at mintedSpecVersion(), which was wrong for any staged bump and not specific to this default - a note on mintedSpecVersion recording what default-on rests on: the events density requirement, and that a sealed log meets it by repair rather than by construction, so the READ has to wait Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * TEMPORARY: point world-vercel at workflow-server#839 preview Validating the seal-poll-budget fix end to end with spec 7 on. Reverted before merge; the override lint guard is expected to fail meanwhile. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * Revert "TEMPORARY: point world-vercel at workflow-server#839 preview" This reverts commit 5e17cc9. --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

vercel Bot deployed to Preview – workbench-python-workflow August 21, 2026 23:19 View deployment

vercel Bot deployed to Preview – workflow-web August 21, 2026 23:20 View deployment

vercel Bot deployed to Preview – workflow-tarballs August 21, 2026 23:20 View deployment

vercel Bot deployed to Preview – workbench-nestjs-workflow August 21, 2026 23:20 View deployment

vercel Bot deployed to Preview – workbench-tanstack-start-workflow August 21, 2026 23:20 View deployment

vercel Bot deployed to Preview – workbench-nitro-workflow August 21, 2026 23:20 View deployment

vercel Bot deployed to Preview – workbench-fastify-workflow August 21, 2026 23:20 View deployment

vercel Bot deployed to Preview – workbench-sveltekit-workflow August 21, 2026 23:20 View deployment

vercel Bot deployed to Preview – workbench-hono-workflow August 21, 2026 23:20 View deployment

vercel Bot deployed to Preview – workbench-astro-workflow August 21, 2026 23:21 View deployment

vercel Bot deployed to Preview – example-nextjs-workflow-webpack August 21, 2026 23:21 View deployment

vercel Bot deployed to Preview – workbench-express-workflow August 21, 2026 23:21 View deployment

vercel Bot deployed to Preview – workbench-vite-workflow August 21, 2026 23:21 View deployment

vercel Bot deployed to Preview – example-nextjs-workflow-turbopack August 21, 2026 23:21 View deployment

vercel Bot deployed to Preview – example-workflow August 21, 2026 23:21 View deployment

vercel Bot deployed to Preview – workbench-nuxt-workflow August 21, 2026 23:21 View deployment

vercel Bot deployed to Preview – workflow-docs August 21, 2026 23:21 View deployment

vercel Bot deployed to Preview – workflow-swc-playground August 21, 2026 23:22 View deployment

VaguelySerious marked this pull request as ready for review August 21, 2026 23:30

VaguelySerious requested review from a team, fantix and msullivan as code owners August 21, 2026 23:30

pranaygp approved these changes Aug 21, 2026

View reviewed changes

vercel Bot temporarily deployed to Preview – workflow-docs August 21, 2026 23:31 Inactive

vercel Bot deployed to Preview – workbench-python-workflow August 21, 2026 23:31 View deployment

vercel Bot deployed to Preview – workflow-web August 21, 2026 23:31 View deployment

vercel Bot deployed to Preview – workbench-nitro-workflow August 21, 2026 23:32 View deployment

vercel Bot deployed to Preview – workbench-express-workflow August 21, 2026 23:32 View deployment

vercel Bot deployed to Preview – workbench-astro-workflow August 21, 2026 23:32 View deployment

vercel Bot deployed to Preview – workbench-nestjs-workflow August 21, 2026 23:32 View deployment

vercel Bot deployed to Preview – workflow-tarballs August 21, 2026 23:32 View deployment

vercel Bot deployed to Preview – workbench-hono-workflow August 21, 2026 23:32 View deployment

vercel Bot deployed to Preview – workbench-fastify-workflow August 21, 2026 23:32 View deployment

vercel Bot deployed to Preview – workbench-vite-workflow August 21, 2026 23:32 View deployment

vercel Bot deployed to Preview – example-workflow August 21, 2026 23:32 View deployment

vercel Bot deployed to Preview – workbench-sveltekit-workflow August 21, 2026 23:32 View deployment

VaguelySerious merged commit b2cac62 into main Aug 21, 2026
76 of 82 checks passed

vercel Bot deployed to Preview – workbench-nuxt-workflow August 21, 2026 23:32 View deployment

VaguelySerious deleted the peter/sealed-log-opt-in branch August 21, 2026 23:32

vercel Bot deployed to Preview – workbench-tanstack-start-workflow August 21, 2026 23:32 View deployment

vercel Bot deployed to Preview – example-nextjs-workflow-turbopack August 21, 2026 23:32 View deployment

vercel Bot deployed to Preview – example-nextjs-workflow-webpack August 21, 2026 23:32 View deployment

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

Version Packages (beta) #3717

Merged

vercel Bot deployed to Preview – workflow-swc-playground August 21, 2026 23:34 View deployment

VaguelySerious mentioned this pull request Aug 22, 2026

Re-enable the sealed log by default #3737

Merged

Navigation Menu

Uh oh!

[world] Make the sealed log opt-in instead of default-on - #3735

[world] Make the sealed log opt-in instead of default-on#3735
VaguelySerious merged 2 commits into
mainfrom
peter/sealed-log-opt-in

VaguelySerious commented Aug 21, 2026 •

edited

Loading

Uh oh!

changeset-bot Bot commented Aug 21, 2026 •

edited

Loading

Uh oh!

vercel Bot commented Aug 21, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 21, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 21, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 21, 2026 •

edited

Loading

Uh oh!

Uh oh!

github-actions Bot commented Aug 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

VaguelySerious commented Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why

1. The Python runtime cannot read a sealed log

2. A truncated sealed-log read makes a completed step look in-flight, and inline ownership then waits out a full 860s lease

Scope

Compatibility

Test plan

Uh oh!

changeset-bot Bot commented Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

🧪 E2E Test Results

❌ Failed E2E Tests

▲ Vercel Production (1 failed)

⚠️ Flaky E2E Tests (passed on retry)

🛠 Infra Events (absorbed by the harness)

E2E Test Summary

Uh oh!

github-actions Bot commented Aug 21, 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 Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Sim World

Uh oh!

Uh oh!

github-actions Bot commented Aug 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

VaguelySerious commented Aug 21, 2026 •

edited

Loading

changeset-bot Bot commented Aug 21, 2026 •

edited

Loading

vercel Bot commented Aug 21, 2026 •

edited

Loading

github-actions Bot commented Aug 21, 2026 •

edited

Loading

github-actions Bot commented Aug 21, 2026 •

edited

Loading

github-actions Bot commented Aug 21, 2026 •

edited

Loading