[world-vercel] Send the run id on correlation-id event reads - #3334
Conversation
#3280 made runId required on ListEventsByCorrelationIdParams, but world-vercel could only apply the scope after the fact: it selected by correlation id on the wire and filtered the returned page by run. That depends on the backend having happened to return the run's rows in the page it answered with. Put runId on the request. The backend reads the run's own partition and answers for that run, so the page comes back scoped. The client-side filter stays for backends that predate the parameter and still answer across runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 8aa1570 The changes in this PR will be included in the next version bump. This PR includes changesets to release 17 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📦 Local Production (1 failed)nitro-stable-node (1 failed):
E2E Test SummarySummary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
❌ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
✅ vercel-multi-region
|
📊 Workflow Benchmarkscommit Backend:
📈 STSO distribution vs main (inline / queue-hop histograms)1020 steps (inline) Cumulative STSO time: main 166837ms → this run 143670ms (Δ -23167ms, -14%) 1020 steps (queue-hop) Cumulative STSO time: main 2968ms → this run 3876ms (Δ +908ms, +31%) ℹ️ 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 |
|
No backport to This commit builds directly on #3280, which is main-only: To override, re-run the Backport to stable workflow manually via |
2 participants
Follow-up to #3280.
#3280 made
runIdrequired onListEventsByCorrelationIdParams, but world-vercel could only apply the scope after the response arrived: it selected by correlation id on the wire and filtered the returned page by run id. A correlation id names a step, hook or wait within its run, so under slot identitystep_…001is the first step of every slot-numbered run, and an unscoped read spans runs. Post-filtering a page the backend chose without knowing the run is not a scope.This sends
runIdon the request, so the backend can answer for that run alone. The client-side filter stays as the fallback for a backend that predates the parameter and still answers across runs (skew protection keeps older deployments talking to the current API, and vice versa).The backend side is tracked separately and ships first.
Tests
events-v4.test.ts:getEventsByCorrelationIdV4puts bothcorrelationIdandrunIdon the query string.events.test.ts:getWorkflowRunEventswith a correlation id sendsrunId, and when a backend answers with two runs sharing one correlation id, only the requested run's event survives whilehasMore/cursorstay the backend's.Both tests were checked against mutations: dropping the
runIdquery param fails the first, dropping the post-filter fails the second.