feat(core): mirror replay lineage into a reserved $replayedFromRunId attribute - #3329
feat(core): mirror replay lineage into a reserved $replayedFromRunId attribute#3329mitul-s wants to merge 2 commits into
Conversation
…attribute recreateRunFromExisting records its source run only in the new run's executionContext, which attribute-indexed observability stores (e.g. the ClickHouse workflow_run_attributes table behind the dashboard runs list) never see — so surfacing 'which runs are replays' in a list requires a per-run world read. Seed the same value as the reserved $replayedFromRunId attribute (like $rootRunId/$parentRunId) on worlds with native attributes; pre-v4 spec versions skip the attribute silently and keep the executionContext record. Co-authored-by: Cursor <cursoragent@cursor.com>
🦋 Changeset detectedLatest commit: 1f2440a 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)nextjs-webpack-node (1 failed):
💻 Local Development (11 failed)astro-stable-quickjs (1 failed):
express-stable-quickjs (1 failed):
fastify-stable-quickjs (1 failed):
hono-stable-quickjs (1 failed):
nextjs-turbopack-canary-quickjs (1 failed):
nextjs-turbopack-stable-quickjs (1 failed):
nextjs-webpack-stable-quickjs (1 failed):
nitro-stable-quickjs (1 failed):
nuxt-stable-quickjs (1 failed):
sveltekit-stable-quickjs (1 failed):
vite-stable-quickjs (1 failed):
📦 Local Production (13 failed)astro-stable-quickjs (1 failed):
express-stable-quickjs (1 failed):
fastify-stable-quickjs (1 failed):
hono-stable-quickjs (1 failed):
nextjs-turbopack-canary-quickjs (1 failed):
nextjs-turbopack-stable-quickjs (1 failed):
nextjs-webpack-canary-quickjs (1 failed):
nextjs-webpack-stable-quickjs (1 failed):
nitro-stable-node (1 failed):
nitro-stable-quickjs (1 failed):
nuxt-stable-quickjs (1 failed):
sveltekit-stable-quickjs (1 failed):
vite-stable-quickjs (1 failed):
🐘 Local Postgres (12 failed)astro-stable-quickjs (1 failed):
express-stable-quickjs (1 failed):
fastify-stable-quickjs (1 failed):
hono-stable-quickjs (1 failed):
nextjs-turbopack-canary-quickjs (1 failed):
nextjs-turbopack-stable-quickjs (1 failed):
nextjs-webpack-canary-quickjs (1 failed):
nextjs-webpack-stable-quickjs (1 failed):
nitro-stable-quickjs (1 failed):
nuxt-stable-quickjs (1 failed):
sveltekit-stable-quickjs (1 failed):
vite-stable-quickjs (1 failed):
🪟 Windows (1 failed)nextjs-turbopack-quickjs (1 failed):
📋 Other (6 failed)e2e-local-dev-nest-stable-quickjs (1 failed):
e2e-local-dev-tanstack-start-quickjs (1 failed):
e2e-local-postgres-nest-stable-quickjs (1 failed):
e2e-local-postgres-tanstack-start-quickjs (1 failed):
e2e-local-prod-nest-stable-quickjs (1 failed):
e2e-local-prod-tanstack-start-quickjs (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 149536ms → this run 130313ms (Δ -19223ms, -13%) 1020 steps (queue-hop) Cumulative STSO time: main 2962ms → this run 3139ms (Δ +177ms, +6%) 📜 Previous results (1)70cc37fTue, 04 Aug 2026 18:00:52 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 |
Composing the replay key around the resolver forced an empty-object sentinel and a separate hasLineage concept; making the resolver own all lineage attributes returns undefined for no-lineage runs and keeps the seed call site in its original shape. Co-authored-by: Cursor <cursoragent@cursor.com>
1 participant
Summary
recreateRunFromExistingrecords its source run only on the new run'sexecutionContext(replayedFromRunId, #2872). Attribute-indexed observability stores never seeexecutionContext— the ClickHouseworkflow_run_attributestable behind the Vercel dashboard's runs list only carries run attributes — so surfacing "which runs are replays" in a list currently requires a per-run world read (see vercel/front#79769, which fans outruns.getManyfor every listed page).This mirrors the replay lineage into the reserved
$replayedFromRunIdattribute, riding the exact mechanism$rootRunId/$parentRunIdalready use:@workflow/world: exportREPLAYED_FROM_RUN_ID_ATTRIBUTE($replayedFromRunId) alongside the existing lineage attribute keys.@workflow/corestart(): whenreplayedFromRunIdis set and the spec version supports native attributes (v4+), seed the attribute on both therun_createdevent and the resilient-start queue input (withallowReservedAttributes, like parent lineage). Pre-v4 runs skip the attribute silently and keep the unconditionalexecutionContextrecord, so replaying an old run never fails.replayedFromRunIdnow runs before the attribute seed is composed; behavior is otherwise unchanged (a plainstart()still emits noattributesfield at all).Once ingested, the dashboard's runs list can serve replay lineage straight from the attributes table and drop the per-run world fan-out.
Testing
packages/core:pnpm vitest run src/runtime/start.test.ts src/runtime/runs.test.ts— 82 passed, including new coverage: attribute seeded on both payloads, merges with caller attributes (caller keys last), skipped on pre-v4 spec withexecutionContextintact, and no emptyattributesobject on plain starts.packages/world: full unit suite — 84 passed.tscshow no new findings (thequickjs-runtime.tstypecheck errors and complexity warnings exist onmain).Made with Cursor