fix(core): order step-result deliveries against wait/hook deliveries by event-log position by pranaygp · Pull Request #3139 · vercel/workflow

pranaygp · 2026-07-27T20:35:30Z

The bug

Two production runs on @workflow/core@5.0.0-beta.36 (o2flow) burned all three divergence-recovery replays at the same eventId and terminated with CORRUPTED_EVENT_LOG:

run	shape	error
`wrun_41KYJENABV0GSF5YTE9EETV5DD`	step vs wait	`Replay divergence: step event step_created for step_X belongs to "A", but the current step consumer is "B"`
`wrun_41KYJEE01S0GPC9RWT5MEKVCX8`	step vs hook	same

Mechanism

useStep proxies draw deterministic ULIDs in invocation order (packages/core/src/step.ts:27), and replay pairs events to consumers by correlationId, erroring on a stepName mismatch (step.ts:88-100). So the ULID→stepName allocation is a pure function of the order in which promise resolutions are delivered to workflow code.

The delivery-barrier registry (ctx.pendingDeliveryBarriers, packages/core/src/private.ts) exists to pin that order to event-log position — its own docstring describes this exact failure class — but it only covered hook payloads and wait completions. Step results were outside it: step_completed resolved straight from its serial promiseQueue slot, and that slot's latency varies wildly between replays of the same invocation:

the first replay pays full hydration (decrypt → decompress → revive);
later replays share the invocation's ReplayPayloadCache and memo-hit small primitive results (replay-payload-cache.ts:125), resolving in one or two microtask hops.

Meanwhile a wait_completed resolves from a detached, fixed-hop chain (workflow/sleep.ts:100-116) that is about four hops off the queue tail. So a step completion adjacent in the log to a wait_completed is delivered wait-first on a cold replay and step-first on a warm one. Whichever order the invocation that wrote the follow-up step_created events happened to observe became law; every replay computing the other order diverged permanently, and since the divergence is deterministic given a warm cache, all three recovery replays hit it at the same event.

The fix

step_completed and step_failed now participate in the barrier registry, mirroring the hook-payload path exactly:

register a 'step' barrier at the event's log index, so later wait/hook deliveries are handed over only after it;
hydrate inside the serial promiseQueue slot (async deserialization stays in log order) but only capture the outcome, releasing pendingDeliveries in the slot's finally;
then, in a detached continuation, await the earlier deliveries before markDelivered() + resolve/reject.

Two details are what actually make the ordering hold. I found both by testing rather than by reading the code, and the first version of this PR had neither.

The deferral set is captured while consuming the event, not at the start of the hydration slot. Slot-start capture is not merely less deterministic — it is usually empty. An earlier delivery whose own slot runs first on the serial queue has typically already resolved and deregistered its barrier before the later slot begins, so the later delivery does not defer at all. Instrumenting the hook case showed exactly that: awaitEarlier kind=step idx=4 defers=0, with the hook's barrier already gone. Every event in one drain window is consumed before any slot runs, so consumption time sees all of them (defers=1).

A delivery that had to wait yields a macrotask before resolving. An earlier delivery being "delivered" only means its resolve() ran. The branch it woke may need arbitrarily many further microtask hops before it reaches its next useStep call and draws a ULID — a for await over a hook resumes the generator, settles the promise from next(), and only then runs the loop body; workflow code may await anything in between. Ordering the resolve() calls alone therefore buys a fixed hop or two of margin and leaves a hop-count race that holds only for the shortest consumers. Yielding a macrotask lets the earlier branch's whole microtask chain drain first, whatever its length. Only deliveries that actually deferred pay it, so the common single-delivery drain is unaffected.

wait_completed and hook_received deliveries symmetrically defer behind earlier step results. step_failed is included because a rejection is just as branch-deciding as a success — it decides whether a catch continuation runs, and therefore which ULIDs follow-up useStep calls draw. It also now holds pendingDeliveries across hydration, which it previously did not.

awaitEarlierDeliveries(ctx, index, kind) now takes the delivering kind instead of an explicit kind list, with a single DEFER_BEHIND table as the source of truth:

delivering	defers behind earlier	why not the rest
`hook`	`wait`, `step`	sequential same-entity payloads must not block one another
`wait`	`hook`, `step`	a wait never needs to queue behind another wait
`step`	`wait`, `hook`	step-vs-step order is already fixed by the serial `promiseQueue`

Deadlock / cycle analysis

No cycles. Every edge points from a later log index to a strictly earlier one, so the wait-for graph is a DAG by construction.
Never await a barrier inside a serial queue slot. Hydration stays in the slot; the barrier wait and the resolve run detached. Blocking a slot on a resolution the queue itself drives would deadlock the queue (the constraint sleep.ts already documents).
pendingDeliveries is released inside the slot, before the detached defer — otherwise scheduleWhenIdle could never reach idle, and the idle safety net that retires abandoned barriers (which this deferral may be waiting on) would never fire. This is the same shape as the hook path and the reason abort-controller.ts bumps the counter.
When no earlier barrier is pending — the overwhelmingly common case — awaitEarlierDeliveries resolves immediately with no macrotask, so the step's resolve is enqueued at the end of its own slot, before the next queue slot runs. Ordering against every other queue-slot-driven delivery (including abort-controller.ts's _setAborted, which is not a barrier participant) is therefore unchanged from before the fix, and no macrotask is paid.
The macrotask cannot strand a delivery. It is a setTimeout(0) awaited in the detached continuation, after pendingDeliveries has already been released in the slot, so it neither blocks the serial queue nor prevents scheduleWhenIdle from reaching idle.
A suspension cannot preempt the deferred resolve, even though scheduleWhenIdle also runs on setTimeout(0) and pendingDeliveries is already 0 by then. The deferred step's macrotask is registered the moment the earlier barrier is marked delivered — i.e. before the woken branch's continuation runs at all — whereas the suspension macrotask is only registered once some branch reaches a useStep past the end of the log, which happens within that continuation's microtask chain. Registration order therefore puts the step's resolve first, and its own continuation (a microtask) draws its ULID before the suspension macrotask fires. The 18 hop-count cases exercise exactly this: each ends in a suspension and asserts that both follow-up steps are pending, which only holds if the deferred delivery landed before the suspension took effect. This does assume workflow continuations are microtask chains, which holds because the sandbox has no real timers — sleep() is a wait event, not a setTimeout.
The idle safety net still covers abandoned step deliveries (workflow suspended before observing the resolution): registerDeliveryBarrier → scheduleWhenIdle(finish) is unchanged.

One deviation from the obvious design, and it is load-bearing

Gating a step result behind every earlier hook barrier — the straightforward reading — is wrong, and the existing suite catches it. A buffered hook payload (no consumer awaiting when hook_received is consumed) is delivered by claim(), i.e. whenever the workflow next reads the hook — which is very commonly downstream of the step result itself (await setupStep() and only then iterator.next()). Gating the step on it stalls the run until the barrier's idle safety net fires, which then releases the step and every delivery queued behind that payload at once; the workflow installs its Promise.race against an already-resolved sleep and loses the very race the ordering exists to protect.

Implemented naively, that regressed 4 existing tests:

FAIL  src/hook-sleep-interaction.test.ts > … > should let a queued hook payload win when a reused wait completes after the step that installs the race
FAIL  src/hook-sleep-interaction.test.ts > … > should let a queued hook payload win without mapping the race promises
      (×2, once per sync/async deserialization mode)
ReplayDivergenceError: Replay divergence: step event step_created for step_01K11TFZ62YS0YYFDQ3E8B9YCY
  belongs to "drainStep", but the current step consumer is "syncNextStep"

So barrier entries carry an armed flag: wait and step are always armed, a hook payload with a waiting consumer is armed at registration, and a buffered payload is registered unarmed and armed by claim(). A step result skips any earlier delivery that will not resolve on its own — unarmed, or transitively blocked on something unarmed (resolvesOnItsOwn). Waits and hooks deliberately keep gating on unclaimed payloads: for them, waiting for the claim is the ordering guarantee (a wait_completed must not preempt a payload the log ordered first). Those 4 tests are now a real regression guard for this asymmetry.

Test evidence

packages/core/src/step-delivery-ordering.test.ts is byte-identical to the file in the repro-only companion PR #3137 apart from two it.fails markers there, which let a repro-only branch have green CI (sed 's/it\.fails(/it(/g' | cmp verifies it). So the tests demonstrably were not bent to fit the fix. Each case replays one committed event log twice through a shared ReplayPayloadCache (production shape: one cache per queue delivery, many replays), with hydrateStepReturnValue stubbed to cost 10ms so only the cold replay pays it.

Five cases, two of which fail on main:

case	on `main`	mirrors
wait vs step, cold replay	passes	—
wait vs step, warm replay	fails	run `wrun_41KYJENABV0GSF5YTE9EETV5DD`
`for await` hook vs step, cold replay	passes	—
`for await` hook vs step, warm replay	fails	run `wrun_41KYJEE01S0GPC9RWT5MEKVCX8`
direct `await hook` vs step, both replays	passes	control for the already-correct path

The hook flavour must use for await (… of hook) to reproduce, but not because the payload is buffered — I instrumented workflow/hook.ts to check, and all three hook cases consume hook_received with an awaiter already registered (promises.length === 1); claim() never runs in any of them. Entering for await calls next(), which reaches yield await this and subscribes well before the events consumer drains the log on process.nextTick.

What actually differs is how many microtask hops separate the payload resolving from the branch calling afterHook() and drawing its next ULID. for await resumes the async generator at yield await this, settles the promise returned by next(), and only then runs the loop body; a memo-warm step_completed — which on an unfixed runtime resolves inside its own queue slot with no detached chain at all — gets there first. A directly-awaited hook resumes its continuation in the first microtask and stays ahead even on a warm cache, which is why it makes a good control: same delivery path, same event log, opposite outcome on main, and this PR changes the code it runs through (the barrier is now registered armed there), so it must stay green.

So the hook flavour is the same hydration-latency race as the wait flavour; the consumer shape only sets how much of a head start the step result needs in order to win. (Buffered payloads are central to the armed design below, but they are exercised by hook-sleep-interaction.test.ts's queued-payload cases — verified by the same instrumentation: promises.length === 0, then claim() → arm() — not by these new tests.)

Without the fix (fix sources reverted to the branch's base commit, converged test file kept):

❯ src/step-delivery-ordering.test.ts (5 tests | 2 failed) 147ms
  × delivers the wait before the step result on a later replay sharing the payload cache
  × delivers the hook payload before the step result on a later replay sharing the payload cache

ReplayDivergenceError: Replay divergence: step event step_created for
  step_01K11TFZ62YS0YYFDQ3E8B9YCX belongs to "afterSleep", but the current step consumer is "afterStep"
 ❯ src/step.ts:91:15

ReplayDivergenceError: Replay divergence: step event step_created for
  step_01K11TFZ62YS0YYFDQ3E8B9YCX belongs to "afterHook", but the current step consumer is "afterStep"
 ❯ src/step.ts:91:15

 Tests  2 failed | 3 passed (5)

This matches the repro PR's independently observed baseline on main exactly — same two cases, same ULID, same error text — and it reproduces the same way in CI, on both Linux and Windows: in #3137's run the two warm-replay cases satisfy their it.fails markers while the other three pass, i.e. the divergence is not an artifact of one machine's timing.

The second test file, and why these five cases are not sufficient

All five cases above are consumed by branches that reach their next useStep call in the fewest possible microtask hops. That makes them unable to distinguish two very different guarantees: (a) step results are delivered in event-log order relative to wait and hook deliveries, or (b) a step result merely resolves a hop or two later than it used to, which beats the shortest consumers and nothing else.

The distinction is not academic, and I only caught it by probing: the first version of this PR provided (b) and passed all five cases anyway. packages/core/src/step-delivery-hop-count.test.ts closes that hole. Each case replays a log a live run legitimately produced — the live invocation received the two events in separate deliveries, so the first branch ran to completion long before the second event existed — while the replay receives both in one drain window and must still allocate the ULIDs in the recorded order. The consumer is padded with 0, 1, 2, 4, 8, or 16 extra awaits so hop count is the only variable, across three groups: step result vs wait completion, step result vs hook payload, and step failure vs wait completion (a rejection decides whether a catch continuation runs, and so which ULID the useStep there draws — step_failed goes through the same registration and capture, so it needs the same guard).

version	hop-count cases passing
`main` (no fix)	0 of 18
resolve-ordering only (this PR's first revision)	3 of 12 of the cases that predated the macrotask
this PR	18 of 18

The middle row is the point: without the event-consumption-time capture and the macrotask yield, a consumer with a single extra await after being resumed still diverges. These cases are the regression guard for the guarantee actually being (a).

With the fix: 5 passed (5) and 18 passed (18). The 15 ordering-sensitive files (both new files plus hook-sleep-interaction, async-deserialization-ordering, abort-replay-ordering, abort-consistency, step-hydration-memoization, workflow, runtime, events-consumer, step, workflow/sleep, workflow/hook, define-hook, runtime/resume-hook) were run 8× consecutively, stable at 321 passed | 3 expected fail every time.

Full core suite (74 files): 1565 passed | 3 expected fail — the 3 expected-fails are pre-existing it.fails cases. Under a colour TTY, log-format, logger, and context-errors additionally report ANSI inline-snapshot mismatches; those fail identically on the unmodified tree and pass under FORCE_COLOR=0, i.e. a local artifact, not a regression. pnpm --filter @workflow/core typecheck is clean, and biome check reports only the two noExcessiveCognitiveComplexity warnings that step.ts already carries on main (63 and 20 there, 63 and 21 here).

Full local e2e against a nextjs-turbopack dev server, re-run after the macrotask change since it shifts real timing: 135 passed (135) — the whole suite, including every AbortController case, cancelRun, hookWithSleepWorkflow, hookWithSleepFinalStepWorkflow, sleepWithSequentialStepsWorkflow, and setAttributes.

CI history. An earlier revision of this branch (3fe83a19, same barrier design, resolve-ordering only) went green across the whole matrix: all 13 E2E Vercel Prod Tests apps, E2E Local Dev, E2E Local Postgres and E2E Local Prod (three world backends, ~10 frameworks each), Unit Tests on Linux and Windows, Lint, Docs Checks, Tarballs Checks, Performance Benchmarks and DCO — tally SUCCESS: 80, SKIPPED: 6, FAILURE: 3. Revision d4f86aa4 (converged test file) likewise passed Unit Tests on both Linux and Windows, with the Linux core-suite line matching my local numbers exactly.

The 3 failures in that tally were E2E Local Prod Tests (nextjs-webpack - stable), (nuxt - stable), and the E2E Required Check gate aggregating them: all the same pre-existing flake, webhookWorkflow hitting its 120s timeout at 1 failed | 153 passed (154). main fails identically at commit 4ada27d3 (same test, same timeout, same counts), so it is unrelated to this change. For the record, the first run on this branch also tripped the documented rotating E2E Vercel Prod flake on 7 apps; main at this branch's exact base commit 4ba223a0 tripped it on 9, and the re-run came back fully green.

CI is re-running on the current revision, which adds the event-consumption-time capture, the macrotask yield, and the hop-count test file.

The companion repro-only PR is #3137 (branch pgp/repro-step-wait-divergence): it adds this same test file without the fix, and its CI confirms on Linux and Windows that the two warm-replay cases diverge on main while the other three hold. Merging that first, then this, gives a red-then-green history for the bug; whoever lands them should flip those two cases back from it.fails to plain assertions as part of merging this PR.

Follow-up: remaining barrier gaps (commit 2)

Review of the first commit turned up three more places the registry did not
reach. Each is fixed here, with a regression test in the new
packages/core/src/delivery-barrier-coverage.test.ts that reproduces the
production ReplayDivergenceError when — and only when — its own fix is
reverted. Verified one at a time.

1. A step must defer behind earlier STEP results

DEFER_BEHIND.step excluded 'step' on the grounds that the serial
promiseQueue already orders step results. That stopped being true in this
PR: a step captures its outcome in its queue slot but resolves from a detached
continuation once its barrier clears. Two steps agree on that ordering only
while they defer behind the same set — true within one drain window, false
across windows. A step consumed later can miss a wait/hook barrier an earlier
step is still parked on, because it retired in between; the earlier step is
then waiting out the macrotask yield while the later one resolves on
microtasks.

The test log is one a live run legitimately produces: stepA's worker writes
step_completed just before the invocation resuming from a sleep writes
step_created stepB, so that invocation's own replay never delivered stepA.
On replay stepB's consumer does not exist until the sleep lands, so the two
completions fall in separate drain windows.

Cost of the extra edge, measured on a parallel step fan-out (Promise.all of
N steps, all completing in one drain): +1.3 ms, flat, not O(N) — the idle
safety net retires the chain in one timer tick rather than serializing N of
them. N=10 3.1→4.4 ms, N=50 3.1→5.2 ms, N=100 6.6→7.8 ms.

2. `sleep.ts` and `hook.ts` must capture their deferral at consumption time

The "Coverage" argument the first commit documents for step.ts applies
symmetrically, and was not applied. sleep.ts read the registry after the
queue tail and hook.ts at the end of its hydration slot — by which point an
earlier step or hook has usually delivered and deregistered its barrier. The
later delivery then skips both the gate and awaitEarlierDeliveries'
macrotask yield, and overtakes the branch that earlier delivery just woke.

This is the exact mirror of step-delivery-hop-count.test.ts and fails the
same way: a wait completion diverges at 8 extra consumer hops, a hook payload
at 20. Both are covered at 0/1/3/8/20/50 hops in the new file.

The buffered hook payload path deliberately keeps evaluating at claim
time, and now says so. A buffered payload's delivery genuinely happens when
the workflow reads the hook, potentially many deliveries later; a
consumption-time snapshot makes the claim wait on barriers from a moment it
never participated in, which stalls the second payload in the e2e
hookWithSleepWorkflow long enough for the run to suspend before delivering
it. Caught by the full local e2e run, not by unit tests.

3. Abort deliveries participate in the registry

abort-controller.ts resolved _setAborted straight off its promiseQueue
slot and registered no barrier. That was sufficient only while every other
delivery also resolved from its slot. _setAborted fires the signal's
listeners, and a listener may invoke a step and draw a ULID, so an abort is as
branch-deciding as any other delivery — a log-earlier step sitting behind a
barrier is overtaken by any abort whose slot runs in the meantime. It now
registers as a 'hook' (which is exactly what the event is), always armed,
and resolves detached behind its deferral.

Also: `resolvesOnItsOwn` was exponential

Each armed entry re-walked every earlier entry of the opposite kind —
T(n) = Σ T(j) — with no memo, on the synchronous delivery path. The registry
is not bounded: EventsConsumer drains consecutively consumable events
synchronously while barriers only retire on microtask-driven deliveries, so a
fan-out of Promise.race([hook, sleep(watchdog)]) branches accumulates one
barrier per branch per kind (49 live barriers measured for 24 branches).

A single scan over 40 alternating armed hook/wait barriers took 92 seconds
of blocked event loop before the fix, and is instant after. Guarded by a test
in the new file that times the synchronous scan.

Verification (commit 2)

pnpm vitest run --root packages/core src/ → 75 files, 1614 passed | 3 expected fail. Typecheck clean. Biome: same 8 pre-existing complexity/banned-type warnings as the unmodified tree, none new.
The 14 ordering-sensitive files 8x consecutively → 277 passed | 3 expected fail every time.
Full local e2e against a nextjs-turbopack dev server: 135 passed (135).
e2e/local-build, e2e/build-errors, e2e/route-bundle-isolation pass individually. Run as one vitest invocation, route-bundle-isolation fails — identically on the unmodified tree, so it is cross-suite build interference, not a regression.

Rollout caveat

In-flight runs whose logs were allocated under the old flipped (step-first) ordering will now deterministically diverge on replay. Those runs were already unrecoverable time bombs under the old runtime — any warm replay computed the other order, which is exactly how these two runs died — so this bounds the blast radius to windows that were already affected rather than creating a new one.

Not a concern for SDK version drift specifically: on Vercel a run is pinned to its originating immutable deployment, so a single run never replays across two different @workflow/core versions. The caveat above is only about logs already written under the old ordering, replayed by the same deployment.

What reviewers should scrutinise

The armed asymmetry (private.ts, resolvesOnItsOwn + awaitEarlierDeliveries): is "a step never queues behind an unclaimed buffered payload" the right line, or should the wait/hook side eventually adopt it too? Today they must not, or the original hook-vs-sleep fix regresses.
arm() timing — the thinnest part of the argument. A buffered payload is armed at claim(), and a step now reads armed-ness while consuming its event, which is exactly log position and cannot depend on hydration duration. The residual sharp edge is a shape where the claim is armed by a continuation of an earlier delivery, i.e. where the arming itself is latency-coupled one level up, so a step consuming its event might see the entry unarmed on one replay and armed on another. I could not construct a case that diverges, and none of the existing tests exhibit it — the new tests never buffer, and hook-sleep-interaction's queued-payload cases claim from a continuation downstream of a step but with only one step delivery in flight. So treat this as unproven rather than verified; it is where I would look first if a similar divergence resurfaces.
Macrotask cost. The barrier's idle safety net contributes one setTimeout(0) per step delivery (cheap; the poll exits the first time pendingDeliveries hits 0), and the new yield adds another only when a delivery actually had to defer — i.e. only when two or more branch-deciding events land in the same drain window, which is rare and is precisely the case that was broken. A sequential single-step workflow pays neither. Still worth a look given the active inline-step perf work, and worth challenging if anyone sees a cheaper way to let a resumed branch quiesce than a macrotask.
step_failed now holds pendingDeliveries across hydration (it did not before), so suspensions wait for a rejection to land. Intentional and consistent with step_completed, but it is a behaviour change beyond pure ordering.
Whether the guarantee should be stated in the docs. What this establishes is: given a fixed delivery order, the userland interleaving that follows is deterministic, so pinning delivery order to log order is sufficient for replay determinism. The hop-count tests encode that. If reviewers agree it is the intended contract, it probably belongs somewhere more discoverable than a test file docstring.

🤖 Generated with Claude Code

changeset-bot · 2026-07-27T20:35:35Z

🦋 Changeset detected

Latest commit: f9c1006

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/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	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-07-27T20:35:37Z

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

Project	Deployment	Actions	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Jul 28, 2026 9:25pm
example-nextjs-workflow-webpack	Ready	Preview, Comment	Jul 28, 2026 9:25pm
example-workflow	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workbench-astro-workflow	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workbench-express-workflow	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workbench-fastify-workflow	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workbench-hono-workflow	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workbench-nestjs-workflow	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workbench-nitro-workflow	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workbench-nuxt-workflow	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workbench-sveltekit-workflow	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workbench-tanstack-start-workflow	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workbench-vite-workflow	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workflow-docs	Ready	Preview, Comment, Open in v0	Jul 28, 2026 9:25pm
workflow-swc-playground	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workflow-tarballs	Ready	Preview, Comment	Jul 28, 2026 9:25pm
workflow-web	Ready	Preview, Comment	Jul 28, 2026 9:25pm

github-actions · 2026-07-27T20:35:55Z

📊 Workflow Benchmarks

commit f9c1006 · Tue, 28 Jul 2026 21:43:16 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric	Scenario	Best (ms)	P75 (ms)	P90 (ms)	P99 (ms)	Samples
TTFS	step	1099 (+55%) 🔻	1166 🔴 (+16%) 🔻	1174 🔴 (+16%) 🔻	1329 🔴 (-12%)	30
TTFS	stream	1110 (+16%) 🔻	1162 🔴 (+18%) 🔻	1199 🔴 (+19%) 🔻	1423 🔴 (+35%) 🔻	30
TTFS	hook + stream	602 (-50%) 💚	1598 🔴 (+24%) 🔻	1640 🔴 (+22%) 🔻	1734 🔴 (+7.7%)	30
STSO	1020 steps (1-20)	158 (-1.3%)	255 🔴 (-0.8%)	332 🔴 (+9.6%)	339 🔴 (-20%) 💚	19
STSO	1020 steps (101-120)	168 (-9.2%)	238 🔴 (-2.9%)	284 🔴 (+1.1%)	333 🔴 (-53%) 💚	19
STSO	1020 steps (1001-1020)	457 (-2.1%)	516 🔴 (-8.7%)	596 🔴 (-2.3%)	618 🔴 (-9.9%)	19
WO	1020 steps	406131 (+5.2%)	406131 (+5.2%)	406131 (+5.2%)	406131 (+5.2%)	1
SL	stream latency	84 (+3.7%)	180 🔴 (+36%) 🔻	202 🔴 (+44%) 🔻	311 🔴 (+74%) 🔻	30
SO	stream overhead (text)	89 (-12%)	146 (-19%) 💚	194 (-4.0%)	2193 🔴 (+777%) 🔻	30
SO	stream overhead (structured)	85 (-14%)	144 (-11%)	180 (-7.7%)	360 (+66%) 🔻	30

📜 Previous results (5)