Slot event identity (SDK 4/4): scope listByCorrelationId to a run - #3247
Slot event identity (SDK 4/4): scope listByCorrelationId to a run#3247VaguelySerious wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: 350af92 The changes in this PR will be included in the next version bump. This PR includes changesets to release 20 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
🧪 E2E Test Results❌ Some tests failed ❌ Failed E2E Tests▲ Vercel Production (1 failed)fastify (1 failed):
E2E Test SummarySummary
Details by Category❌ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 📋 Other
✅ vercel-multi-region
|
4e89132 to
04efaec
Compare
e20895c to
73199f0
Compare
📊 Workflow Benchmarkscommit Backend:
📈 STSO distribution vs main (inline / queue-hop histograms)1020 steps (inline) Cumulative STSO time: main 437759ms → this run 451743ms (Δ +13984ms, +3%) 1020 steps (queue-hop) Cumulative STSO time: main 8262ms → this run 7134ms (Δ -1128ms, -14%) 📜 Previous results (3)09f8e32Sat, 01 Aug 2026 20:52:27 GMT · run logs
d8f5792Fri, 31 Jul 2026 21:46:43 GMT · run logs
f55cdf1Fri, 31 Jul 2026 21:03:08 GMT · run logs
ℹ️ Metric definitions & methodologyThe collapsed STSO distribution section above buckets every step gap of the sequential-steps run (not a sampled window), split by whether the step ending the gap ran inline — in the same warm process as the step before it, so the gap is pure framework overhead — or after a queue-hop — the first step of a fresh process, which pays queue dispatch, client reinit and event-log replay. Bars overlay the two runs: Best/P75/P90/P99 deltas compare against the most recent benchmark run on Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window) 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 · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost 🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000 All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor ( Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the |
A correlation id identifies a step or wait within its run, not across runs. That was invisible while every id carried a ULID, and it stops being invisible once a run numbers its own steps: `step_…001` names the first step of every slot-numbered run, so an unscoped lookup answers with one event per run, and a cursor — an event id — cannot tell two such rows apart. `ListEventsByCorrelationIdParams` gains an optional `runId`. The Local and Postgres Worlds filter on it, which also makes their cursor a key again; the Vercel World routes analytics to the run-scoped endpoint it already has and applies the scope to the page for the runtime read, whose backend index is keyed by correlation id alone. The observability search passes the run it is already looking at, and keeps its own post-filter for a world that cannot scope.
Event Log Race Repro2 of 14 latest repro runs hit event-log regressions. Run History
Latest Scenario Breakdown
Latest Non-Completed Runs
The |
1 participant
Stacked on #3246. Review the last commit only.
Why
A correlation id identifies a step or wait within its run, not across runs. Nothing enforced that while every id carried a ULID, so the distinction never mattered. It matters as soon as a run numbers its own steps:
step_…001names the first step of every slot-numbered run.Measured on the Local World before this change — two runs, each with one step, one unscoped lookup:
Two consequences:
runId, so nothing wrong is displayed — but it pages against a bounded page cap, so the run it wants can sit past the cap and the search reports nothing found.eventId. Two runs can hold the same correlation id at the same slot, soeventId > cursorskips the sibling row at the equal id. Scoped,(run_id, id)is the primary key, so the cursor is a key again.Nothing in the runtime reads this path — it is an observability read — so this is not a correctness regression in a run. It is a read that gets quietly wrong answers under slot identity.
What
ListEventsByCorrelationIdParams(and the analytics variant) gain an optionalrunId.AND run_id = $n, which also disambiguates the cursorhasMorestay the backend'sThe observability search passes the run it is already looking at, and keeps its post-filter as defence for a world that cannot scope.
Leaving the param optional keeps every existing caller working, and an unscoped lookup still means "every run that numbered one the same" — which is the honest answer to the question asked.
Tests
Both slot-identity suites gain the pair, and Postgres gains the cursor case:
Local 524 pass, Postgres 184 pass (real container), world 98, core 1687 + 3 expected fail, world-vercel 317, web 94.
Follow-up
The backend index behind the Vercel runtime read is keyed by correlation id alone, so a slot-mode
step_…001is a hot key across all runs and the scope is applied client-side. Taking a run scope there is a backend-side change, tracked separately.Stack: #3228 → #3234 → #3246 → #3247
Paired backend stack (world-vercel side): 6 PRs, all rebased on main and stacked;
WORKFLOW_SERVER_URL_OVERRIDEpoints at the top of it and must be reverted before merge.