Description
Workflows deployed to Vercel never execute or register. start() enqueues the run (and sometimes throws itself), but every outbound call the SDK makes to vercel-workflow.com — and every queue delivery to /.well-known/workflow/v1/flow — fails with TypeError: fetch failed caused by Cannot read private member #u from an object whose class did not declare it.
Observable consequences:
- Workflows dashboard stays on the "Get Started" empty state — run events (
run_created, run_started) all fail (Observability → External APIs shows vercel-workflow.com at 100% error rate, 1–5 ms latency)
- Observability → Queues shows the workflow queue with messages received 27 times, deleted 0 — the handler never acknowledges
- Runs retry until the delivery budget exhausts ("Queue message exhausted safety limit (256 attempts)")
The identical code works fine in local dev (local world).
Error
From production function logs (/.well-known/workflow/v1/flow, invoked by vercel-queue/v2beta):
[workflow] Queue handler failed for message "1v-1M1UwuuovWNgqVai0wLGPyCfGRAZ3WM6" on delivery attempt 1; retrying in 1s: TypeError: fetch failed
at async (.next/server/chunks/[root-of-the-server]__06jy23u._.js:6:1584)
at async (.next/server/chunks/[root-of-the-server]__06jy23u._.js:5:28701)
at async iq (.next/server/chunks/[root-of-the-server]__06jy23u._.js:19:7908)
...
[cause]: TypeError: Cannot read private member #u from an object whose class did not declare it
at new Promise (<anonymous>)
}
Note the stack is entirely inside a Turbopack-compiled chunk, and #u is a minified private field — Node's own undici uses readable names (#state, #headersList), so the failing class is a bundled copy meeting an object from another copy.
Environment
workflow: 4.8.0 (@workflow/world-vercel 4.6.1, @workflow/next 4.1.4)
- Next.js 16.3, App Router, Turbopack build, pnpm monorepo
- Vercel production deployment, region dub1
- Fails identically on Node.js 22.x and 24.x — not Node-version related (we tested both via the
engines override)
- Cron route calls
start(workflowFn, [args]); workflow orchestrates ~9 "use step" functions
Suspected cause
Two copies of the fetch/Request machinery end up in the deployed bundle (the SDK's client compiled into the Turbopack chunk vs. the runtime's), and an object constructed by one copy is passed to the other; accessing a private class field through the foreign instance throws. Same bug class as payloadcms/payload#15116 (fixed there by forwarding the original target as receiver in proxy traps). Possibly Turbopack-build-specific — local dev (also Turbopack, unbundled runtime) is unaffected.
Reproduction
- Next.js 16.3 app with
withWorkflow, Turbopack production build, deployed to Vercel
- Call
start() from a route handler
- Queue message is created; every delivery fails with the error above; nothing ever appears in the Workflows dashboard; External APIs shows 100% errors to vercel-workflow.com
Workaround
None found within the SDK — pinning Node.js to 22.x does not help (same failure). We currently execute the same step functions inline (steps called outside a workflow run as plain functions) and keep the durable path behind an env flag. Untested: whether a webpack build avoids it.
Description
Workflows deployed to Vercel never execute or register.
start()enqueues the run (and sometimes throws itself), but every outbound call the SDK makes tovercel-workflow.com— and every queue delivery to/.well-known/workflow/v1/flow— fails withTypeError: fetch failedcaused byCannot read private member #u from an object whose class did not declare it.Observable consequences:
run_created,run_started) all fail (Observability → External APIs showsvercel-workflow.comat 100% error rate, 1–5 ms latency)The identical code works fine in local dev (local world).
Error
From production function logs (
/.well-known/workflow/v1/flow, invoked byvercel-queue/v2beta):Note the stack is entirely inside a Turbopack-compiled chunk, and
#uis a minified private field — Node's own undici uses readable names (#state,#headersList), so the failing class is a bundled copy meeting an object from another copy.Environment
workflow: 4.8.0 (@workflow/world-vercel4.6.1,@workflow/next4.1.4)enginesoverride)start(workflowFn, [args]); workflow orchestrates ~9"use step"functionsSuspected cause
Two copies of the fetch/Request machinery end up in the deployed bundle (the SDK's client compiled into the Turbopack chunk vs. the runtime's), and an object constructed by one copy is passed to the other; accessing a private class field through the foreign instance throws. Same bug class as payloadcms/payload#15116 (fixed there by forwarding the original target as receiver in proxy traps). Possibly Turbopack-build-specific — local dev (also Turbopack, unbundled runtime) is unaffected.
Reproduction
withWorkflow, Turbopack production build, deployed to Vercelstart()from a route handlerWorkaround
None found within the SDK — pinning Node.js to 22.x does not help (same failure). We currently execute the same step functions inline (steps called outside a workflow run as plain functions) and keep the durable path behind an env flag. Untested: whether a webpack build avoids it.