WorkflowNotRegisteredError persists across 5+ deployments (including no-cache rebuild) on Vercel production

Summary

start(workflowFn, [args]) reliably triggers a workflow run on Vercel, but every run since 2026-07-14T11:28 UTC fails at the /.well-known/workflow/v1/flow endpoint with:

WorkflowNotRegisteredError: Workflow "workflow//./src/workflows/score-submission//scoreSubmissionWorkflow"
is not registered in the current deployment. This usually means a run was started against a deployment
that does not have this workflow, or there was a build/bundling issue.

This has persisted across 5 separate production deployments on the same Vercel project, including one built with the build cache explicitly disabled, over a span of roughly 15 hours with gaps as long as 5+ hours between deployments. Build logs for every one of these deployments report a clean, successful workflow build (workflows build complete (10 steps, 1 workflow, ...)), and the deployed function bundle contains the expected /.well-known/workflow/v1/* routes. The failure appears to be a mismatch between the deployment's own registered handler and whatever Vercel's Queue/routing layer is dispatching the run against — not a build-artifact problem.

Environment

• Framework: Next.js 16.2.6, Turbopack, Node.js engine >=24.0.0
• Workflow DevKit: workflow npm package, locked to exact 4.6.0 in package-lock.json (latest stable 4.x at time of writing)
• Deployment target: Vercel ("Vercel World" backend), production environment

Timeline

What we ruled out

1. Application code. Diffed every commit between the last confirmed-good deployment and the first broken one. The only two commits in that window touched a single numeric constant + comment in the workflow file, and a glob pattern value inside an already-existing next.config.ts key. Neither is a plausible trigger. A later deployment that changed only a markdown doc file also failed identically, definitively ruling out application code.
2. Dependency drift. package-lock.json did not change at all across this window. workflow is pinned to exactly 4.6.0, also the latest stable 4.x release on npm at the time — no newer compatible version to have silently drifted to.
3. Build cache corruption. The first broken build's log showed a restored build cache from an unrelated commit's prior deployment, followed by an up to date in 2s install step, suggesting a possibly-mismatched cached node_modules. We forced a deployment with the build cache explicitly disabled (genuine from-scratch install, confirmed in the build log). It failed identically, ruling this out.
4. Deployment-churn-induced race condition. Initial working theory: unusually frequent redeploys (concurrent development sessions on this project) were racing against Vercel's deployment↔queue-routing bookkeeping. Checking the actual gaps between deployments disproved this — the bug first appeared after a 9.84-hour gap with no intervening deploys, and persisted through subsequent gaps of 5.11h, 3.31h, and 5.07h, far from a rapid-fire clustering pattern that would explain a transient race.

What we found in the docs

node_modules/workflow/docs/deploying/world/vercel-world.mdx describes the underlying mechanism:

"During the build step, the Workflow SDK registers each handler as only reachable by Vercel Queue, by using the experimentalTriggers configuration in .vc-config.json... Only messages delivered through Vercel Queues can trigger execution."

"On Vercel, workflow runs are pegged to the deployment that started them... New workflow runs start on the latest deployment."

This suggests registration is not purely a build-artifact property — it depends on Vercel's own platform-level association between a deployment and its Vercel Queues consumer registration (an explicitly experimental feature per this doc). Our working hypothesis is that this association became stale, or was never correctly (re-)established, for this project — independent of anything in our build or code. We have no way to inspect or repair this from outside the platform, and we don't have a paid support plan to open a ticket through Vercel directly, which is why we're filing here.

Impact

Every workflow run on this project has failed since 2026-07-14T11:28 UTC — the workflow step never begins execution, so no step-level error surfaces, and the run never resolves. The application is pre-launch with no live customer traffic, but the durable-job pipeline (the app's core async workload) is currently completely non-functional in production.

Reproduction

1. Call start(myWorkflow, [args]) from an API route on a Vercel production deployment.
2. Observe POST /.well-known/workflow/v1/flow in the runtime logs immediately afterward, returning 200 at the HTTP layer but logging [Workflow] Error while running workflow { errorCode: 'RUNTIME_ERROR', errorName: 'WorkflowNotRegisteredError', ... }.
3. The workflow's return value / any side effects it should have written never materialize.

What we'd like maintainers to check

• Whether this project's deployment↔Vercel-Queues-consumer registration can end up in a stale or bad state independent of the build artifact
• Whether there's a way to force-resync that registration without relying on redeploys (5 attempts have not resolved it)
• Whether this is a known failure mode of the experimental Vercel Queues integration under any specific condition that could be worked around going forward

Happy to share the Vercel project/team IDs and deployment IDs privately if that helps a maintainer look at the platform-side registration state directly.

Read node_modules/workflow/docs/deploying/world/vercel-world.mdx first, then trace the production POST /.well-known/workflow/v1/flow behavior across the listed deployment IDs. Compare the documented Vercel Queue registration model with the reported deployments and determine whether registration can be resynchronized or reproduced as a platform integration failure.