[core] Prune schema modules from workflow bundles - #3550
Conversation
🦋 Changeset detectedLatest commit: b035250 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 |
7f68db4 to
4a2cc23
Compare
🧪 E2E Test Results❌ Some tests failed ❌ Failed E2E Tests▲ Vercel Production (31 failed)express-node (1 failed):
express-quickjs (1 failed):
hono-quickjs (2 failed):
nest-quickjs (2 failed):
nextjs-webpack-quickjs (2 failed):
nitro-node (2 failed):
nitro-quickjs (4 failed):
nuxt-quickjs (2 failed):
python-node (8 failed):
sveltekit-quickjs (2 failed):
tanstack-start-quickjs (2 failed):
vite-quickjs (3 failed):
🌐 Cross-language Conformance (9 failed)python (9 failed):
|
| Passed | Failed | Skipped | Total | |
|---|---|---|---|---|
| ❌ ▲ Vercel Production | 3547 | 31 | 742 | 4320 |
| ✅ 💻 Local Development | 3922 | 0 | 558 | 4480 |
| ✅ 📦 Local Production | 3922 | 0 | 558 | 4480 |
| ✅ 🐘 Local Postgres | 3922 | 0 | 558 | 4480 |
| ✅ 🪟 Windows | 320 | 0 | 0 | 320 |
| ❌ 🌐 Cross-language Conformance | 0 | 9 | 132 | 141 |
| ✅ vercel-multi-region | 27 | 0 | 0 | 27 |
| Total | 15660 | 40 | 2548 | 18248 |
Details by Category
❌ ▲ Vercel Production
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-node | 132 | 0 | 28 |
| ✅ astro-quickjs | 132 | 0 | 28 |
| ✅ example-node | 132 | 0 | 28 |
| ✅ example-quickjs | 132 | 0 | 28 |
| ❌ express-node | 131 | 1 | 28 |
| ❌ express-quickjs | 131 | 1 | 28 |
| ✅ fastify-node | 132 | 0 | 28 |
| ✅ fastify-quickjs | 132 | 0 | 28 |
| ✅ hono-node | 132 | 0 | 28 |
| ❌ hono-quickjs | 130 | 2 | 28 |
| ✅ nest-node | 132 | 0 | 28 |
| ❌ nest-quickjs | 130 | 2 | 28 |
| ✅ nextjs-turbopack-node | 157 | 0 | 3 |
| ✅ nextjs-turbopack-quickjs | 157 | 0 | 3 |
| ✅ nextjs-webpack-node | 157 | 0 | 3 |
| ❌ nextjs-webpack-quickjs | 155 | 2 | 3 |
| ❌ nitro-node | 130 | 2 | 28 |
| ❌ nitro-quickjs | 128 | 4 | 28 |
| ✅ nuxt-node | 132 | 0 | 28 |
| ❌ nuxt-quickjs | 130 | 2 | 28 |
| ❌ python-node | 0 | 8 | 152 |
| ✅ sveltekit-node | 151 | 0 | 9 |
| ❌ sveltekit-quickjs | 149 | 2 | 9 |
| ✅ tanstack-start-node | 132 | 0 | 28 |
| ❌ tanstack-start-quickjs | 130 | 2 | 28 |
| ✅ vite-node | 132 | 0 | 28 |
| ❌ vite-quickjs | 129 | 3 | 28 |
✅ 💻 Local Development
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-stable-node | 134 | 0 | 26 |
| ✅ astro-stable-quickjs | 134 | 0 | 26 |
| ✅ express-stable-node | 134 | 0 | 26 |
| ✅ express-stable-quickjs | 134 | 0 | 26 |
| ✅ fastify-stable-node | 134 | 0 | 26 |
| ✅ fastify-stable-quickjs | 134 | 0 | 26 |
| ✅ hono-stable-node | 134 | 0 | 26 |
| ✅ hono-stable-quickjs | 134 | 0 | 26 |
| ✅ nest-stable-node | 134 | 0 | 26 |
| ✅ nest-stable-quickjs | 134 | 0 | 26 |
| ✅ nextjs-turbopack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-turbopack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-turbopack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-turbopack-stable-quickjs | 160 | 0 | 0 |
| ✅ nextjs-webpack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-webpack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-webpack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-webpack-stable-quickjs | 160 | 0 | 0 |
| ✅ nitro-stable-node | 134 | 0 | 26 |
| ✅ nitro-stable-quickjs | 134 | 0 | 26 |
| ✅ nuxt-stable-node | 134 | 0 | 26 |
| ✅ nuxt-stable-quickjs | 134 | 0 | 26 |
| ✅ sveltekit-stable-node | 153 | 0 | 7 |
| ✅ sveltekit-stable-quickjs | 153 | 0 | 7 |
| ✅ tanstack-start-node | 134 | 0 | 26 |
| ✅ tanstack-start-quickjs | 134 | 0 | 26 |
| ✅ vite-stable-node | 134 | 0 | 26 |
| ✅ vite-stable-quickjs | 134 | 0 | 26 |
✅ 📦 Local Production
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-stable-node | 134 | 0 | 26 |
| ✅ astro-stable-quickjs | 134 | 0 | 26 |
| ✅ express-stable-node | 134 | 0 | 26 |
| ✅ express-stable-quickjs | 134 | 0 | 26 |
| ✅ fastify-stable-node | 134 | 0 | 26 |
| ✅ fastify-stable-quickjs | 134 | 0 | 26 |
| ✅ hono-stable-node | 134 | 0 | 26 |
| ✅ hono-stable-quickjs | 134 | 0 | 26 |
| ✅ nest-stable-node | 134 | 0 | 26 |
| ✅ nest-stable-quickjs | 134 | 0 | 26 |
| ✅ nextjs-turbopack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-turbopack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-turbopack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-turbopack-stable-quickjs | 160 | 0 | 0 |
| ✅ nextjs-webpack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-webpack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-webpack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-webpack-stable-quickjs | 160 | 0 | 0 |
| ✅ nitro-stable-node | 134 | 0 | 26 |
| ✅ nitro-stable-quickjs | 134 | 0 | 26 |
| ✅ nuxt-stable-node | 134 | 0 | 26 |
| ✅ nuxt-stable-quickjs | 134 | 0 | 26 |
| ✅ sveltekit-stable-node | 153 | 0 | 7 |
| ✅ sveltekit-stable-quickjs | 153 | 0 | 7 |
| ✅ tanstack-start-node | 134 | 0 | 26 |
| ✅ tanstack-start-quickjs | 134 | 0 | 26 |
| ✅ vite-stable-node | 134 | 0 | 26 |
| ✅ vite-stable-quickjs | 134 | 0 | 26 |
✅ 🐘 Local Postgres
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ astro-stable-node | 134 | 0 | 26 |
| ✅ astro-stable-quickjs | 134 | 0 | 26 |
| ✅ express-stable-node | 134 | 0 | 26 |
| ✅ express-stable-quickjs | 134 | 0 | 26 |
| ✅ fastify-stable-node | 134 | 0 | 26 |
| ✅ fastify-stable-quickjs | 134 | 0 | 26 |
| ✅ hono-stable-node | 134 | 0 | 26 |
| ✅ hono-stable-quickjs | 134 | 0 | 26 |
| ✅ nest-stable-node | 134 | 0 | 26 |
| ✅ nest-stable-quickjs | 134 | 0 | 26 |
| ✅ nextjs-turbopack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-turbopack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-turbopack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-turbopack-stable-quickjs | 160 | 0 | 0 |
| ✅ nextjs-webpack-canary-node | 141 | 0 | 19 |
| ✅ nextjs-webpack-canary-quickjs | 141 | 0 | 19 |
| ✅ nextjs-webpack-stable-node | 160 | 0 | 0 |
| ✅ nextjs-webpack-stable-quickjs | 160 | 0 | 0 |
| ✅ nitro-stable-node | 134 | 0 | 26 |
| ✅ nitro-stable-quickjs | 134 | 0 | 26 |
| ✅ nuxt-stable-node | 134 | 0 | 26 |
| ✅ nuxt-stable-quickjs | 134 | 0 | 26 |
| ✅ sveltekit-stable-node | 153 | 0 | 7 |
| ✅ sveltekit-stable-quickjs | 153 | 0 | 7 |
| ✅ tanstack-start-node | 134 | 0 | 26 |
| ✅ tanstack-start-quickjs | 134 | 0 | 26 |
| ✅ vite-stable-node | 134 | 0 | 26 |
| ✅ vite-stable-quickjs | 134 | 0 | 26 |
✅ 🪟 Windows
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ nextjs-turbopack-node | 160 | 0 | 0 |
| ✅ nextjs-turbopack-quickjs | 160 | 0 | 0 |
❌ 🌐 Cross-language Conformance
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ❌ python | 0 | 9 | 132 |
✅ vercel-multi-region
| App | Passed | Failed | Skipped |
|---|---|---|---|
| ✅ nextjs-turbopack | 27 | 0 | 0 |
📊 Workflow Benchmarkscommit Backend:
Streams
📈 STSO distribution vs main (inline / queue-hop histograms)1020 steps (inline) Cumulative STSO time: main 182882ms → this run 189661ms (Δ +6779ms, +4%) 📈 CRTT drill-down vs main (RTT distributions & profiles)RTT over stream progress (avg per tenth of stream, bars scaled min→max): RTT by chunk size (avg per log size bin, ~160B → ~12KB serialized, bars scaled min→max): Delivery jitter over stream progress (avg positive CDV per tenth of stream, bars scaled min→max): ℹ️ Metric definitions & methodologyStreams: first-chunk RTT (the stream-open path, before any buffering/backpressure), CRTT percentiles, and worst delivery stall (CDV max). Cells are medians across iterations; per-run values in the artifacts. No 🔴/🟢 marks until targets attach. The collapsed STSO distribution section above buckets every step gap, split inline (same warm process — pure framework overhead) vs queue-hop (fresh process — dispatch, reinit, replay). The collapsed CRTT drill-down: per-variant RTT histograms (fixed log bins, 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) · Fan-out TTFS: fan-out time to first step (in-deployment start() → first of the parallel step bodies to complete) · Fan-out TTLS: fan-out time to last step (in-deployment start() → last of the parallel step bodies to complete, i.e. when the Promise.all resolves) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · CRTT: chunk round-trip time (per-chunk write → read latency, one clock domain: deployment → stream backend → same deployment) · CDV: chunk delay variation / delivery jitter (inter-arrival gap minus inter-write gap per seq-adjacent pair; skew-free; the row is each run's MAX positive value, so one stall moves it) 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 · Promise.all(100 steps): 100 trivial no-op steps started together in a single Promise.all; Fan-out TTFS is the first of them to complete and Fan-out TTLS the last, both from the in-deployment clientStart, so their gap is the spread the runtime adds across the fan-out · paced control (100/s, 60B): the control: 300 tiny (~60B) deltas metronome-paced at 100/s — zero workload structure, so it reads the transport floor and flush cadence, and disambiguates transport-wide vs workload-specific when a replay row moves · size sweep (100/s, 160B-12KB): same pacing as the control with deltas padded in rotation across seven log-spaced sizes (~160B–12KB) — rotation decouples size from stream position, so it isolates whether chunk size causes latency · replay gateway-gpt-5.4-nano-2000t (1x): raw provider SSE cadence captured at the AI gateway boundary (gpt-5.4-nano, the most popular gateway model; per-token deltas p50 208B = the modal production chunk size), replayed exactly as measured — the typical customer's workload; its CDV is the typical customer's real delivery jitter · replay eve-gpt-5.6-sol-2000t (1x): a captured eve turn (gpt-5.6-sol, the most-used demanding eve model; ~2000 output tokens = production p50 turn length) replayed exactly as measured — eve's envelope protocol re-ships the cumulative message so sizes ramp 142B→13KB; the demanding outlier tenant's reality · replay eve-gpt-5.6-sol-2000t (2x): the same eve capture at 2x — the headroom/stress row; real fast-tier models emit the same chunk sizes at proportionally higher rate, so time compression is a faithful speed model · first chunk (pooled): every run's seq-0 RTT pooled across all stream scenarios — the first chunk precedes any workload differentiation, so pooling samples one shared stream-open path with exact percentiles Replay cadences (semantic sha256) — eve-gpt-5.6-sol-2000t 🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 All timestamps are deployment-side; runs are triggered in-deployment, so the CI runner and api.vercel.com sit outside every measured window. TTFS = Cold starts stay in the numbers (real bursty-workload latency, inflates P75+); Best is the warm floor. |
8edf496 to
35bea10
Compare
VaguelySerious
left a comment
There was a problem hiding this comment.
AI review: no blocking issues
| } | ||
| }); | ||
|
|
||
| it('does not bundle world schemas into a workflow without schemas', async () => { |
There was a problem hiding this comment.
AI Review: Note
The guard builds a workflow with no imports at all, which is the one shape that can't regress for the interesting reason. I built workbench/example on this branch and on the merge base to check the claim against a real app:
| marker in the VM bundle | base | this PR |
|---|---|---|
| bundle chars | 1,346,292 | 1,300,002 |
EventTypeSchema |
25 | 0 |
SerializedDataSchema |
25 | 0 |
WorkflowInvokePayloadSchema |
2 | 0 |
AttributeChangesSchema |
2 | 0 |
workflowRunIdSchema |
1 | 0 |
_zod |
478 | 478 |
So the World-schema pruning does hold on a real app, including one that uses attributes, hooks and steps. But zod itself is unchanged there, because that app's own workflow file pulls it in through an agent/tool schema. Worth saying in the PR body and changeset that "Zod modules in the VM bundle: 77 → 0" applies to workflows that don't import zod themselves; any workflow with a zod tool schema keeps the whole library. The p50 evaluation number will read as universal otherwise.
A second case in this file driving a workflow that imports from workflow (attributes + hook + step) would pin the part that can actually regress: a value import creeping back into a VM-reachable module.
| AttributeChangesSchema, | ||
| AttributeKeySchema, | ||
| AttributeValidationError, | ||
| AttributeValueSchema, |
There was a problem hiding this comment.
AI Review: Note
This drops four exported values (validateAttributeKey, validateAttributeValue, EVENT_DATA_PAYLOAD_FIELD_BY_EVENT_TYPE, EVENT_DATA_REF_FIELDS) and two exported types (AttributeValidationContext, AttributeKeyValidationOptions) from a published package under a patch changeset.
I checked and found no consumers: nothing in this repo outside the moved definitions, and nothing in the server, dashboard, API or queue-service repos imports them. So patch is defensible. Flagging it only so the removal is a decision rather than a side effect of the file split.
| } | ||
| } | ||
|
|
||
| function attributeCountDelta( |
There was a problem hiding this comment.
AI Review: Note
attributeCountDelta returns 0 for a null value when existingKeys is undefined. The old code did netDeletes += 1 in that branch, so a delete used to offset an add even when nothing was known to exist. Your new test ("does not let an unknown deletion offset a new attribute") pins the new behavior and I agree it's the correct one.
It is a semantic change to a validation function callers can hit, though, so "This changes dependency boundaries only; workflow behavior and serialized formats are unchanged" in the description isn't quite accurate. A batch of 65 sets plus one delete used to pass without existingKeys and now throws. Worth one line in the changeset.
I convinced myself the read path is safe: AttributeChangesSchema now runs the batch constraints when parsing an attr_set event, but with existingKeys undefined the count check is strictly looser than the write-time one, and the schema deliberately allows reserved $ keys, so $rootRunId / $parentRunId events still parse. Good call keeping the reserved-namespace rule out of the schema.
| return event.eventType === 'noop'; | ||
| } | ||
|
|
||
| /** Groups events that are mutually exclusive outcomes for one entity. */ |
There was a problem hiding this comment.
AI Review: Nit
Two things on this move:
-
The rationale on
ENTITY_EVENT_CLASS_BY_TYPEcollapsed from ~20 lines to one. The dropped part is the bit that's hard to reconstruct: whyhook_received,hook_conflict,attr_set,run_createdand the terminal run types are deliberately absent, and specifically that an entry for the terminal run types could never match because no consumer takes them. That is the kind of note someone will otherwise re-derive from an incident. Please carry it over. -
getOwnPropertyfixes a live bug worth naming in the changeset:EVENT_DATA_REF_FIELDSwas built withObject.fromEntries, sogetEventDataRefFields('constructor')returnedObjectrather than falling through to[], andentityEventClass('toString')returned a function. Your new test covers both. That is user-visible for oddeventTypevalues, not just a refactor.
Also packages/world-vercel/src/events.ts:237 still refers readers to "the warning on EVENT_DATA_PAYLOAD_FIELD_BY_EVENT_TYPE", which no longer exists under that name.
Summary
@workflow/worldsubpathsResult
For the 97-step benchmark workflow:
Review scope
This changes dependency boundaries only; workflow behavior and serialized formats are unchanged.
Validation