Uh oh!
There was an error while loading. Please reload this page.
Remove retired v1 step route plumbing - #3061
Conversation
🦋 Changeset detectedLatest commit: 636f5bf The changes in this PR will be included in the next version bump. This PR includes changesets to release 22 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✅ All tests passed E2E Test SummarySummary
Details by Category✅ ▲ Vercel Production
✅ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
✅ vercel-multi-region
|
📊 Workflow Benchmarkscommit Backend:
📜 Previous results (4)c5c2d02Fri, 24 Jul 2026 07:01:04 GMT · run logs
8a4d0ceFri, 24 Jul 2026 00:12:33 GMT · run logs
411e693Thu, 23 Jul 2026 23:45:45 GMT · run logs
1e21d3cThu, 23 Jul 2026 04:55:15 GMT · run logs
ℹ️ Metric definitions & methodologyBest/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 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120 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 |
1e21d3c to
bb7fb14Compare411e693 to
8a4d0ceCompare
TooTallNate
left a comment
There was a problem hiding this comment.
Reviewed this as a reachability audit — for a −3,800-line retirement the question is whether anything still depends on the removed plumbing — and everything checks out. Approving.
The no-producer claim verified against main, not just asserted:
- world-vercel's topic discovery already excluded
*_wkf_step_*topics on main ("intentionally excluded" — pre-existing), and no first-party code path enqueues to a step prefix. The producers went away when the combined handler shipped; this PR removes only the stranded consumer/plumbing side. - The 1,180-line
step-handler.tsdeletion is genuinely dead code: the combined flow route executes queued step messages (workflow-topic payloads carryingstepId) throughexecuteStep— the same background-step path the inline-ownership work built on — so queued steps remain independently executable exactly as the description says. Theruntime.tsdiff is correspondingly surgical: dead re-exports, the health-check endpoint parameter, and comment wording; the live inline/background execution paths are untouched. - The CI-matrix change is the honest rename (
generatedStepPath→generatedStepRegistrationPath) reflecting what the artifact now is — step registrations inside the flow route, not a route.
Semver discipline is right: majors on every package losing published API (QueueKind, StepInvokePayload, HealthCheckEndpoint, the step route type, the CLI flag), patches where only internals changed. On the pre-release line these fold into the next beta, but the majors carry the correct signal into the v5 graduation math.
Verified locally: full build; core 1472 (+3 pre-existing expected-fails), builders 460, utils 109, world 73, world-local 478, world-postgres 162 (including the Testcontainers queue/recovery suites), world-vercel 296, next 26 — all green. CI is 100/100 with zero failures, including every e2e lane across dev/prod/postgres/Vercel-prod — which is the strongest possible empirical proof that no framework's build or runtime reaches the removed code.
Two asks, neither blocking:
- world-postgres upgrade note: removing the
workflow_stepsgraphile task means a self-hosted operator upgrading across this boundary with ancientworkflow_stepsjobs still queued gets handler-not-found failures on those jobs. The window is small (producers stopped many betas ago), but postgres worlds are the one place old jobs can persist indefinitely. A release-note line ("drain or clearworkflow_stepsjobs before upgrading") — or a one-release no-op tombstone task that logs-and-completes — would make the boundary operator-safe. - Do not backport. Stable 4.x still runs separate step routes; the backport bot should decline this on its own criteria (builds on main-only combined-handler architecture), but given a mistaken backport would sever stable's step execution entirely, an explicit no-backport note on the PR is cheap insurance.
One micro-note: createWorkflowUrl traded the never-based exhaustiveness check for a runtime throw — fine with a single variant, just worth restoring the compile-time pattern if a second route type ever returns.
VaguelySerious
left a comment
There was a problem hiding this comment.
LGTM
his removes published legacy types and options, including QueueKind, StepInvokePayload, HealthCheckEndpoint, the step workflow URL route, and workflow health --endpoint
We should keep the QueueKind IMO and the rest is fine to remove
No backport to This is a large breaking refactor that deletes the v1 step route runtime, step queue topics, To override, re-run the Backport to stable workflow manually via |
Summary
/flowhandlerWhy
The combined flow handler has executed steps inline or from workflow-queue continuations since the framework builders stopped emitting a standalone
/steproute. The old handler, queue kind, and adapter branches remained in the repository despite having no current first-party producer and no deployable route target.Postgres still registered both
workflow_flowsandworkflow_steps, selected/flowor/stepfrom the queue prefix, and tested both paths. Current runtime messages only use__wkf_workflow_*; queued step work is represented byrunId,stepId, andstepNameonWorkflowInvokePayload. This removes the unreachableworkflow_stepstask and always delivers through/flow. Step messages remain independently executable rather than being serialized with workflow replay messages.Impact
This removes published legacy types and options, including
QueueKind,StepInvokePayload,HealthCheckEndpoint, thestepworkflow URL route, andworkflow health --endpoint. Changesets are included as required by the repository release process.Validation
pnpm typecheck— 46 packages passedpnpm --filter @workflow/core test— 1,473 passed, 3 expected failurespnpm --filter @workflow/builders test— 228 passedpnpm --filter @workflow/next test— 26 passedpnpm --filter @workflow/utils test— 109 passedpnpm --filter @workflow/world-local test— 478 passedpnpm --filter @workflow/world-vercel test— 296 passedpnpm test:docs— 964 passed; two unrelated existingSandbox.sandboxIdsample failures remain in the V4/V5 sandbox cookbookDocs Preview