Uh oh!
There was an error while loading. Please reload this page.
perf(core): decouple workflow VM seed/clock from startedAt - #2525
Merged
Conversation
Derive the deterministic RNG seed from `runId:workflowName:deploymentId` and the VM's initial fixed clock from the ULID timestamp embedded in `runId` (via the new `runIdCreatedAt` helper). All of these inputs are available the instant a queue message arrives, so the VM seed and clock no longer depend on `startedAt` (set only after the `run_started` round-trip). This is the prerequisite for starting VM initialization earlier on the critical path. This changes the seed-derived value sequence for a given run, so the affected deterministic test fixtures are regenerated accordingly.
🦋 Changeset detectedLatest commit: e9725ac The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 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 |
Contributor
Contributor
📊 Benchmark Results
workflow with no steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express workflow with 1 step💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 10 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 25 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 50 sequential steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.all with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express Promise.all with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.all with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.race with 10 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.race with 25 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Promise.race with 50 concurrent steps💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 10 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express workflow with 25 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 50 sequential data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 10 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 25 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) workflow with 50 concurrent data payload steps (10KB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) Stream Benchmarks(includes TTFB metrics)workflow with stream💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) stream pipeline with 5 transform steps (1MB)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express 10 parallel streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Next.js (Turbopack) | Express fan-out fan-in 10 streams (1MB each)💻 Local Development
▲ Production (Vercel)
🔍 Observability: Express | Next.js (Turbopack) SummaryFastest Framework by WorldWinner determined by most benchmark wins
Fastest World by FrameworkWinner determined by most benchmark wins
Column Definitions
Worlds:
❌ Some benchmark jobs failed:
Check the workflow run for details. |
Contributor
🧪 E2E Test Results✅ All tests passed Summary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
|
| } = createContext({ | ||
| seed: `${workflowRun.runId}:${workflowRun.workflowName}:${+startedAt}`, | ||
| fixedTimestamp: +startedAt, | ||
| seed: `${workflowRun.runId}:${workflowRun.workflowName}:${workflowRun.deploymentId}`, |
There was a problem hiding this comment.
would this stringify as undefined in non-vercel environments?
VaguelySerious
approved these changes
Jun 18, 2026
pranaygp
left a comment
Contributor
There was a problem hiding this comment.
Reviewed the seed/clock decoupling closely — the core change is correct and replay-safe:
- Seed stability:
seedrandom(seed)invm/index.tsis the only RNG input (fixedTimestamponly drivesDate), so changing the seed source doesn't perturb the clock and vice-versa. The new seedrunId:workflowName:deploymentIdis replay-stable:runIdis the ULID (fixed), anddeploymentIdis read from the persisted run snapshot (a requiredz.string()), notprocess.env.VERCEL_DEPLOYMENT_ID— so it's the creation-time pinned deployment and is identical on every replay, even if execution somehow lands on a newer deployment.runIdalone already guarantees uniqueness, as the comment notes. - Clock stability:
fixedTimestamp = runIdCreatedAt(runId) ?? +createdAt.createdAtis a requiredz.coerce.date(), so the fallback can't beNaN. Good call using??rather than||— a decoded epoch of0won't wrongly trigger the fallback. The branch taken depends only onrunId, so it's deterministic per run. Net effect is also a small improvement: the pre-first-event clock now starts at ~createdAt and advances monotonically torun_started, instead of jumping backward fromstartedAt. - The seed formula is reconstructed nowhere else in non-test code (no server/step-executor copy to drift), and the regenerated fixtures keep the same
01HK153X00time prefix with only the random tail changing — exactly consistent with timestamp-from-startedAt/ randomness-from-seed. CI Unit Tests pass on ubuntu + windows, and the dynamic self-validating test (workflow.test.ts:5188) derives IDs from the new formula.
LGTM. One optional reuse nit inline.
| * legacy/non-ULID id, or a test fixture like `wrun_test`); callers fall back to | ||
| * an authoritative timestamp from the run snapshot (`createdAt`) in that case. | ||
| */ | ||
| export function runIdCreatedAt(runId: string): number | undefined { |
Contributor
There was a problem hiding this comment.
Optional (non-blocking): this re-implements "strip a prefix, then decode the ULID time" that already lives in @workflow/world as ulidToDate() (and validateUlidTimestamp() does the exact prefix-strip + decode). @workflow/core already depends on @workflow/world and imports values from it (e.g. SPEC_VERSION_SUPPORTS_COMPRESSION in workflow.ts), and ulidToDate is exported from the package root, so this could fold into:
import{ulidToDate}from'@workflow/world';exportfunctionrunIdCreatedAt(runId: string): number|undefined{constulidPart=runId.startsWith(RUN_ID_PREFIX)
? runId.slice(RUN_ID_PREFIX.length)
: runId;returnulidToDate(ulidPart)?.getTime();}Bonus: ulidToDate validates via z.string().ulid() (stricter than a bare decodeTime in try/catch) and returns null for non-ULIDs, which ?.getTime() turns into undefined — same contract you have now. Reasonable to keep it self-contained in core if you'd rather not couple the early-init path to the world util, but worth a look.
pranaygp
enabled auto-merge (squash)
June 18, 2026 21:56
Uh oh!
There was an error while loading. Please reload this page.
github-actionsBot
added a commit
that referenced
this pull request
Jun 18, 2026
Derive the deterministic RNG seed from `runId:workflowName:deploymentId` and the VM's initial fixed clock from the ULID timestamp embedded in `runId` (via the new `runIdCreatedAt` helper). All of these inputs are available the instant a queue message arrives, so the VM seed and clock no longer depend on `startedAt` (set only after the `run_started` round-trip). This is the prerequisite for starting VM initialization earlier on the critical path. This changes the seed-derived value sequence for a given run, so the affected deterministic test fixtures are regenerated accordingly. Signed-off-by: Nathan Rajlich <n@n8.io>
Contributor
Backport PR opened against |
pranaygp added a commit
that referenced
this pull request
Jun 18, 2026
…testing * origin/main: perf(core): decouple workflow VM seed/clock from startedAt (#2525) [world-local] [core] Cache local dev server port per process (#2522) Show pending runs as gray animated stripes in trace viewer (#2520) [world-vercel] Route v4 event requests through global fetch (#2514) [core] Send workflowName with step events (#2511) Stamp run IDs on world spans (#2508) Reject empty-string hook tokens in createHook() (#2490) perf(core): cache compiled workflow-bundle vm.Script across replays (#2471) perf(core): drain consumable replay events synchronously (#2473) perf(core): lazy inline step start (save one world round-trip per step) (#2478)
This was referenced Jun 19, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
runId:workflowName:deploymentId(dropping thestartedAttimestamp component) and its initial fixed clock from the ULID timestamp embedded inrunId.startedAt(which is only known after therun_startedround-trip).run_started).Details
packages/core/src/runtime/run-id-time.ts(new):runIdCreatedAt(runId)decodes the creation time from awrun_<ulid>run ID, returningundefinedfor non-ULID ids (e.g. test fixtures) so callers fall back to the run snapshot'screatedAt.packages/core/src/workflow.ts: seed is nowrunId:workflowName:deploymentId; initialfixedTimestampcomes fromrunIdCreatedAt(runId) ?? +workflowRun.createdAt.startedAtis still used forgenerateUlidtime and theworkflowStartedAtmetadata exposed to user code.The initial
fixedTimestamponly governsDate.now()/new Date()in the window before the first event is consumed;updateTimestampthen advances the VM clock to each consumed event'screatedAt, starting withrun_created.Behavior change / migration note
Changing the seed formula changes every seed-derived value (step/hook correlation ID ULIDs, nanoids,
crypto.getRandomValues,randomUUID) for a given run. Runs started before this change must not be replayed across the upgrade — they would diverge. Acceptable on the beta channel.Testing
runId:workflowName:deploymentIdformula.runIdCreatedAt.@workflow/coresrc/tests pass (1251). The only failing suites are the pre-existing environment-dependente2e/tests (fail identically onmain).Changeset
@workflow/core: minor (includes the in-flight-replay migration note)Follow-up
The structural change — splitting
runWorkflowinto prepare/execute and kicking off context creation beforerun_started— is intentionally left as a focused follow-up so it can be benchmarked in isolation. This PR is the foundation that unblocks it.