Skip to content

Take the ws events transport only once its handshake is done - #3732

Draft
shalabhc wants to merge 1 commit into
mainfrom
ws-register-after-open
Draft

Take the ws events transport only once its handshake is done#3732
shalabhc wants to merge 1 commit into
mainfrom
ws-register-after-open

Conversation

@shalabhc

Copy link
Copy Markdown
Collaborator

resolveWsTransport treated presence in the transports map as "writable".
Since openWsChannel registers synchronously and connects afterwards, a write
landing in between resolved the transport and then awaited the in-flight
connect — so the first write of a run paid the entire handshake.

The measurement

One WS-enabled deployment, 7 days, grouped by event type and transport:

event transport p50 p95 n
run_started ws 269ms 3,771ms 295
run_started http 79ms 134ms 182
step_started ws 62ms 876ms 2506
step_completed ws 66ms 521ms 2588
run_completed ws 68ms 207ms 444

WS writes cost ~65ms once the socket is up. run_started is 4× that at p50 and
~50× at p95, and slower over the socket than over HTTP. The excess is the
handshake.

run_started is the only event that lands there: it is the runtime's first
write, and 34% of them already fell back to HTTP because they arrived before the
dynamic import('./ws-transport.js') even resolved. Those 34% were taking the
faster path by accident. This change makes that deliberate and total.

Same shape on the older cohort — beta.38 fell back 45.6% of the time, beta.39
34.3% — so this is structural, not a regression in either version.

What changed

One getter and one condition. isReadyForWrites reports whether the socket is
OPEN; resolveWsTransport requires it in addition to map membership.

Membership still answers "does this run have a channel", so refcounting and
sharing across concurrent invocations are untouched — this only narrows what the
write path considers usable. A reconnect reads as not-ready for the same
reason: frames queued behind it are better served by the transport that needs no
setup.

The tradeoff, stated plainly

This widens the HTTP fallback window on purpose — from "until the dynamic
import resolves" to "until the socket is open". Expect the WS share of
run_started to drop toward zero and the ws/http split of everything else to be
unchanged. What it buys is that no write ever blocks on a handshake, and the p95
tail on the first write of a run goes away.

If the goal were instead to maximise WS share, the opposite fix applies — hoist
the import so registration happens earlier — but the latency data says that
would be optimising for the wrong thing: it would make more writes wait for
the socket, not fewer.

Tests

549 passing in packages/world-vercel. Eight existing tests failed on the first
run and all eight were correct to fail: the conformance harness issued its write
before opening the fixture socket, so under the new rule it would have asserted
on a socket nothing was sent through. It now completes the handshake first.

Added withholds the channel until the handshake completes, which pins the new
contract directly — mid-connect resolves null, post-open resolves the
transport — so a future revert fails a test that says why rather than something
incidental.

Not addressed here

The fallback is still silent. resolveWsTransport returning null logs nothing
and tags nothing, which is why establishing any of the above took four
triangulating queries against @vercel.deployment_id. A
workflow.events.transport_fallback attribute on the HTTP span would make this
a one-query answer; worth doing separately.

@changeset-bot

changeset-bot Bot commented Aug 21, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 6dc7e54

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

This PR includes changesets to release 17 packages
Name Type
@workflow/world-vercel Patch
@workflow/cli Patch
@workflow/core Patch
@workflow/web Patch
workflow Patch
@workflow/world-testing Patch
@workflow/builders Patch
@workflow/next Patch
@workflow/nitro Patch
@workflow/vitest Patch
@workflow/web-shared 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

vercel Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

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

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

@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

🧪 E2E Test Results

Some tests failed

❌ Failed E2E Tests

▲ Vercel Production (3 failed)

nextjs-turbopack-node (1 failed):

  • AbortController abortThrowIfAbortedWorkflow: throwIfAborted causes FatalError, no retries

nuxt-quickjs (1 failed):

  • outputStreamInsideStepWorkflow - getWritable() called inside step functions | wrun_41M0KDWJSR0GQXR9K0EA5A3H9P | 🔍 observability

sveltekit-node (1 failed):

  • outputStreamWorkflow negative startIndex (reads from end)

vercel-ws-transport (1 failed)

example (1 failed):

  • thisSerializationWorkflow - step function invoked with .call() and .apply() | wrun_41M0KDYBR90GZYCWYS6FG4NRSS

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

18 flaky tests
  • abortDeterministicBranchFromStepWorkflow: branches stay consistent when abort comes from a step (example)
  • abortThrowIfAbortedWorkflow: throwIfAborted causes FatalError, no retries (example)
  • abortThrowIfAbortedWorkflow: throwIfAborted causes FatalError, no retries (nitro)
  • cancelRun via CLI - cancelling a running workflow (nextjs-turbopack)
  • getChunks returns same content as reading the stream (nitro)
  • getTailIndex returns correct index after stream completes (nextjs-turbopack)
  • hookWithSleepWorkflow - hook payloads delivered correctly with concurrent sleep (nextjs-webpack)
  • importMetaUrlWorkflow - import.meta.url is available in step bundles (example)
  • negative startIndex (reads from end) (hono)
  • negative startIndex (reads from end) (nest)
  • outputStreamInsideStepWorkflow - getWritable() called inside step functions (tanstack-start)
  • positive startIndex (skips first chunk) (express)
  • promiseAllWorkflow (sveltekit)
  • regular Error retries until success (astro)
  • regular Error retries until success (nextjs-webpack)
  • regular Error retries until success (nuxt)
  • retainedInterleavingWorkflow (hono)
  • sleepInLoopWorkflow - sleep inside loop with steps actually delays each iteration (vite)

🛠 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 00:29:18Z · abandoned wrun_01M0KDXK505J82EBENS9M52SAF
  • run-pickup-stall · hookWithSleepFinalStepWorkflow - step only on final payload (nuxt) · at 00:31:11Z · abandoned wrun_01M0KE1DJ9J53327G00ASS9D22

E2E Test Summary

Summary
Passed Failed Skipped Total
❌ ▲ Vercel Production 3575 3 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-http-transport 817 0 143 960
✅ vercel-multi-region 27 0 0 27
❌ vercel-ws-transport 552 1 87 640
Total 17066 4 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 156 1 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 131 1 28
✅ python-node 8 0 152
❌ sveltekit-node 150 1 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 9 0 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 131 1 28
✅ express 132 0 28
✅ nextjs-turbopack 157 0 3
✅ vite 132 0 28

📋 View full workflow run

@github-actions

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

📊 Workflow Benchmarks

commit 6dc7e54 · Sat, 22 Aug 2026 00:49:14 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric Scenario Best (ms) P75 (ms) P90 (ms) P99 (ms) Samples
TTFS step 226 (-78%) 💚 1332 🔴 (+17%) 🔻 1360 🔴 (+15%) 🔻 1419 🔴 (+8.5%) 30
TTFS stream 275 (-74%) 💚 1357 🔴 (+20%) 🔻 1395 🔴 (+20%) 🔻 1415 🔴 (+17%) 🔻 30
TTFS hook + stream 696 (-43%) 💚 1593 🔴 (+12%) 1637 🔴 (+9.4%) 1952 🔴 (+1.2%) 30
Fan-out TTFS Promise.all(100 steps) 568 (-24%) 💚 882 (-54%) 💚 1026 (-47%) 💚 1961 (-3.4%) 10
Fan-out TTLS Promise.all(100 steps) 5071 (+0.8%) 6375 (-15%) 6443 (-18%) 💚 7303 (-15%) 💚 10
STSO 1020 steps (inline) 70 (-33%) 💚 127 (-11%) 148 (-8.1%) 243 (+25%) 🔻 1019
WO 1020 steps 127553 (-11%) 127553 (-11%) 127553 (-11%) 127553 (-11%) 1
CRTT first chunk (pooled) 113 (-7.4%) 177 (+0.6%) 250 (+14%) 384 (-30%) 💚 28

Streams

Scenario CRTT 1st p75 p90 p99 CDV max iters
paced control (100/s, 60B) 174 (+27%) 174 (-63%) 230 (-65%) 454 (-92%) 127 (-18%) 10
size sweep (100/s, 160B-12KB) 129 (-21%) 176 (-12%) 356 (+16%) 795 (+75%) 181 (-2%) 10
replay gateway-gpt-5.4-nano-2000t (1x) 142 (-21%) 128 (-51%) 165 (-71%) 431 (-70%) 274 (-66%) 3
replay eve-gpt-5.6-sol-2000t (1x) 150 (±0%) 143 (-24%) 186 (-46%) 292 (-78%) 281 (-65%) 2
replay eve-gpt-5.6-sol-2000t (2x) 131 (-26%) 189 (-30%) 250 (-34%) 681 (-4%) 237 (-36%) 3
📈 STSO distribution vs main (inline / queue-hop histograms)

1020 steps (inline)

Cumulative STSO time: main 142387ms → this run 127349ms (Δ -15038ms, -11%)

 50-100 ms  ┃                         main   0  this   3    +3
100-150 ms  ███████████████████████┃  main 869  this 920   +51
150-200 ms  █┃██                      main 143  this  80   -63
200-250 ms  ┃                         main   5  this   6    +1
250-300 ms  ┃                         main   2  this   5    +3
300-350 ms  ┃                         main   0  this   3    +3
350-400 ms  ┃                         main   0  this   1    +1
500-550 ms  ┃                         main   0  this   1    +1
📈 CRTT drill-down vs main (RTT distributions & profiles)
variant  RTT 1ms→5s+             avg         p50         p90         p99     n
control  ······▃█▂····  135.5 (-76%)  121 (-20%)  230 (-65%)  454 (-92%)  3000
sweep    ······▃█▂▁···  143.9 (-14%)  124 (-18%)  356 (+16%)  795 (+75%)  3000
gw 1x    ·····▁▆█▁▁···  116.4 (-42%)  107 (-22%)  165 (-71%)  431 (-70%)  5295
eve 1x   ·····▁▅█▁····  120.3 (-31%)  109 (-17%)  186 (-46%)  292 (-78%)  5186
eve 2x   ·····▁▂█▃▁···  160.2 (-21%)  140 (-20%)  250 (-34%)   681 (-4%)  7779

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

control  █▄▄▃▁▁▁▂▂▃  119–182ms
sweep    ▂▂▂▃▅▁▁▁▂█  129–190ms
gw 1x    ▃▃▄▅▃▁▃██▅  104–131ms
eve 1x   ▄▄▆▃▁▄█▆▃▂  104–141ms
eve 2x   ▂▁▃▂▄▂▄█▆▁  129–222ms

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

sweep  ▂██▅▅▁▁  142–146ms

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

control  ▄▆█▃▂▃▁█▃▇  33–50ms
sweep    ▁▂▄▇▂▂▄▂▃█  52–78ms
gw 1x    ▂▂▂▁▁▁▃█▃▄  31–45ms
eve 1x   ▁▆▄▁▄▅█▆▃▅  21–28ms
eve 2x   █▅▁▅▄▁▃█▃▆  24–32ms
📜 Previous results (1)

052a14e

Fri, 21 Aug 2026 22:59:25 GMT · run logs

vercel / nextjs-turbopack

Metric Scenario Best (ms) P75 (ms) P90 (ms) P99 (ms) Samples
TTFS step 398 (-40%) 💚 1428 🔴 (+25%) 🔻 1465 🔴 (+26%) 🔻 3121 🔴 (+152%) 🔻 30
TTFS stream 981 (+209%) 🔻 1389 🔴 (+19%) 🔻 1426 🔴 (+19%) 🔻 1452 🔴 (+6.3%) 30
TTFS hook + stream 1238 (+167%) 🔻 1686 🔴 (+16%) 🔻 1710 🔴 (+13%) 1873 🔴 (+18%) 🔻 30
Fan-out TTFS Promise.all(100 steps) 570 (+0.5%) 2058 (+7.1%) 2073 (-5.6%) 2100 (-35%) 💚 10
Fan-out TTLS Promise.all(100 steps) 1847 (+4.7%) 3911 (-16%) 💚 4235 (-11%) 8845 (+72%) 🔻 10
STSO 1020 steps (inline) 131 (+4.8%) 175 (-12%) 198 (-13%) 418 (+6.9%) 1019
WO 1020 steps 177116 (-8.6%) 177116 (-8.6%) 177116 (-8.6%) 177116 (-8.6%) 1
CRTT first chunk (pooled) 107 (+1.9%) 158 (-3.7%) 213 (-60%) 💚 387 (-53%) 💚 28

Streams

Scenario CRTT 1st p75 p90 p99 CDV max iters
paced control (100/s, 60B) 130 (-12%) 202 (-67%) 282 (-71%) 831 (-27%) 154 (-72%) 10
size sweep (100/s, 160B-12KB) 131 (+3%) 155 (-4%) 223 (-39%) 679 (+32%) 147 (+2%) 10
replay gateway-gpt-5.4-nano-2000t (1x) 135 (-17%) 136 (-9%) 173 (-7%) 491 (+53%) 194 (-16%) 3
replay eve-gpt-5.6-sol-2000t (1x) 164 (-46%) 133 (-78%) 168 (-81%) 247 (-82%) 203 (-81%) 2
replay eve-gpt-5.6-sol-2000t (2x) 157 (-3%) 163 (-42%) 208 (-61%) 325 (-65%) 196 (-66%) 3
ℹ️ 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

github-actions Bot commented Aug 21, 2026

Copy link
Copy Markdown
Contributor

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

Full trace: world-sim.txt

resolveWsTransport treated map membership as 'writable'. A write landing
between openWsChannel and the socket opening therefore resolved the
transport and awaited the in-flight connect, so the first write of a run
paid the whole handshake.

Measured on one WS-enabled deployment over 7 days, run_started:

  ws    p50 269ms   p95 3771ms   (n=295)
  http  p50  79ms   p95  134ms   (n=182)

against ~65ms p50 for every write issued after the socket was up. Going
over the socket made that write slower than not using the socket at all,
and the 34% of run_started writes already falling back were taking the
faster path by accident.

Membership still answers 'does this run have a channel' - the refcount
and sharing across concurrent invocations are unchanged. The write path
now additionally asks whether a frame can go out without setup first. A
reconnect reads as not-ready for the same reason.

This widens the HTTP fallback window on purpose: from 'until the dynamic
import resolves' to 'until the socket is open'. What it buys is that no
write ever blocks on a handshake.

Co-Authored-By: opencode <opencode@vercel.com>

Co-Authored-By: shalabhc <shalabh.chaturvedi@vercel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant