Vercel World Regression: getWorkflowMetadata() fully breaking runs

[pablodecm]

Summary

workflow@4.2.0-beta.74 breaks multiple of our real Next.js workflow flows in the Vercel world.

The same flow works in:

• workflow@4.2.0-beta.72

and fails in:

• workflow@4.2.0-beta.74

The failure happens inside a valid "use step" function that calls getWorkflowMetadata() / getStepMetadata().

The exact error we get on Vercel is:

getWorkflowMetadata() can only be called inside a workflow or step function

What is important here is:

• this is a real flow in our app, not just a synthetic test
• the same flow works on beta.72
• the same reduced repro works for us in local Next world
• it fails in Vercel world on beta.74

So from our side this looks like a regression in beta.74, specifically in the Vercel world execution path.

Versions

• next: 16.2.1
• node: 24.x
• working: workflow@4.2.0-beta.72
• broken: workflow@4.2.0-beta.74

Minimal (AI) repro

We reduced it to this workflow:

import { getStepMetadata, getWorkflowMetadata } from "workflow";

export interface MetadataContextReproInput {
  label?: string;
}

export interface MetadataContextReproResult {
  label: string;
  workflowRunId: string;
  workflowStartedAt: string;
  stepId: string;
  attempt: number;
  stepStartedAt: string;
}

const withStrictMetadataCheck = async <T>(fn: () => Promise<T>) => {
  const workflowMetadata = getWorkflowMetadata();
  const stepMetadata = getStepMetadata();

  return await fn().then((result) => ({
    result,
    workflowMetadata,
    stepMetadata,
  }));
};

const metadataContextReproStep = async ({
  label = "metadata-context-repro",
}: MetadataContextReproInput): Promise<MetadataContextReproResult> => {
  "use step";

  const { workflowMetadata, stepMetadata } = await withStrictMetadataCheck(async () => label);

  return {
    label,
    workflowRunId: workflowMetadata.workflowRunId,
    workflowStartedAt: workflowMetadata.workflowStartedAt.toISOString(),
    stepId: stepMetadata.stepId,
    attempt: stepMetadata.attempt,
    stepStartedAt: stepMetadata.stepStartedAt.toISOString(),
  };
};

export const metadataContextReproWorkflow = async (
  input: MetadataContextReproInput,
): Promise<MetadataContextReproResult> => {
  "use workflow";

  return await metadataContextReproStep(input);
};

And this route:

import { start } from "workflow/api";
import { metadataContextReproWorkflow } from "@/server/lib/workflow/repros/metadata-context-repro.workflow";

export const POST = async (request: Request) => {
  const body = await request.json().catch(() => ({}));

  try {
    const run = await start(metadataContextReproWorkflow, [
      {
        label: typeof body.label === "string" && body.label.length > 0 ? body.label : undefined,
      },
    ]);

    const result = await run.returnValue;

    return Response.json({
      ok: true,
      result,
    });
  } catch (error) {
    return Response.json(
      {
        ok: false,
        error: error instanceof Error ? error.message : String(error),
        stack: error instanceof Error ? error.stack : undefined,
      },
      { status: 500 },
    );
  }
};

That can be triggered with:

curl -X POST https://<deployment>/api/workflow-metadata-repro \
  -H 'content-type: application/json' \
  -d '{"label":"smoke-test"}'

Actual behavior on Vercel with 4.2.0-beta.74:
This is the exact response we get:

{
  "ok": false,
  "error": "Workflow run \"wrun_01KN46H2XC7V3WRECB61EZ4SKJ\" failed: Step \"step//./src/server/lib/workflow/repros/metadata-context-repro.workflow//metadataContextReproStep\" failed after 3 retries: `getWorkflowMetadata()` can only be called inside a workflow or step function"
}

The stack includes:

Caused by: Error: `getWorkflowMetadata()` can only be called inside a workflow or step function
    at ...
    at withStrictMetadataCheck (...)
    at metadataContextReproStep (...)

So this is definitely being thrown from inside metadataContextReproStep, which is a valid "use step" function.

Repro matrix

• workflow@4.2.0-beta.72 + Vercel world: works
• workflow@4.2.0-beta.74 + Vercel world: fails
• workflow@4.2.0-beta.74 + local Next world: works

Why this looks like a framework regression

This does not look like invalid API usage because:

• getWorkflowMetadata() / getStepMetadata() are called inside a valid "use step"
• they are not called at module top level
• the same real flow works on beta.72
• the same reduced repro works locally
• the failure is specific to Vercel world on beta.74

Possible relation

I am not certain about root cause, but this may be related to recent builder/runtime regressions in the same version window.

A few upstream items that looked relevant while investigating:

• Support projects with Node.js step dependencies in vitest plugin #1524 Support projects with Node.js step dependencies in vitest plugin
• [builders] Fix .ts extension rewrite regression for non-vitest frameworks #1560 [builders] Fix .ts extension rewrite regression for non-vitest frameworks
• getStepMetadata failing inside of step function #599 getStepMetadata failing inside of step function

I do not want to overstate this, since this specific repro is in Vercel world and not necessarily the exact same bug. But the failure mode looks similar: metadata helpers behaving as if step context is missing inside a valid step.

Possibly relevant detail

In this repro, "use workflow" and "use step" are in the same file. I am not sure whether that is required to trigger the issue, but it may be relevant.

Question

Is there a known regression between 4.2.0-beta.72 and 4.2.0-beta.74 in the Vercel world that could cause step metadata context to be missing inside a valid "use step"?

[VaguelySerious]

(AI) Reproduction

Reproduced the pattern locally by adding the exact repro code (module-level helper calling getWorkflowMetadata()/getStepMetadata() from inside a "use step" function) to the e2e test suite. The test passes locally in both dev and production modes, consistent with the issue report that this only fails on Vercel world deployments.

Root cause

When Vercel's production bundler creates multiple copies of the context-storage.js module (the file that holds the AsyncLocalStorage instance), two separate AsyncLocalStorage instances are created. The step handler calls contextStorage.run() on one instance, but user code calling getWorkflowMetadata()/getStepMetadata() reads from a different instance via contextStorage.getStore(), which returns undefined.

This is the same class of bug documented in #599 and #839 — dual module instances breaking the singleton AsyncLocalStorage context.

Related issues

• getStepMetadata failing inside of step function #599 — Same root cause: getStepMetadata failing inside step due to dual AsyncLocalStorage instances (different import paths)
• AsyncLocalStorage context lost in tool execution (regression in beta.40) #839 — Same pattern: AsyncLocalStorage context lost in AI SDK tool callbacks due to bundler module duplication

Fix

PR #1591 makes the step context AsyncLocalStorage a process-wide singleton by storing it on globalThis via Symbol.for('WORKFLOW_STEP_CONTEXT_STORAGE'). This ensures a single shared instance regardless of how many times the module is loaded by a bundler. The pattern mirrors what the workflow VM context already does with Symbol.for('WORKFLOW_CONTEXT').

[VaguelySerious]

To see if this fix solves your issue, could you try to install the pre-release in your package.json? Just replace the workflow dep like so:

{
  "dependencies": {
    "workflow": "https://workflow-docs-git-peter-issue-1577.vercel.sh/workflow.tgz",
    "@workflow/ai": "https://workflow-docs-git-peter-issue-1577.vercel.sh/workflow-ai.tgz",
  }
}

[pablodecm]

Hi @VaguelySerious, thank for the fast response, I installed the pre-release and tested and seems that it does not fix it at least for now. The weird thing is that in workflow@4.2.0-beta.72 it worked just fine.

Step "step//./src/server/lib/workflow/instrumentation//captureWorkflowErrorStep" failed after 3 retries: `getWorkflowMetadata()` can only be called inside a workflow or step function

Error: `getWorkflowMetadata()` can only be called inside a workflow or step function
    at /var/task/apps/web/.next/server/chunks/_0m~_v8v._.js:11:53529
    at withStepInstrumentation (/var/task/apps/web/.next/server/chunks/_0m~_v8v._.js:897:8280)
    at captureWorkflowErrorStep (/var/task/apps/web/.next/server/chunks/_0m~_v8v._.js:897:9237)
    at /var/task/apps/web/.next/server/chunks/node_modules__pnpm_0wgp3_o._.js:21:49596
    at AsyncLocalStorage.run (node:internal/async_local_storage/async_context_frame:63:14)
    at /var/task/apps/web/.next/server/chunks/node_modules__pnpm_0wgp3_o._.js:21:49312
    at /var/task/apps/web/.next/server/chunks/node_modules__pnpm_0wgp3_o._.js:14:41275
    at AsyncLocalStorage.run (node:internal/async_local_storage/async_context_frame:63:14)
    at /var/task/node_modules/.pnpm/next@16.2.1_@babel+core@7.29.0_@opentelemetry+api@1.9.0_@playwright+test@1.58.2_babel-p_0d1b5d63011c4a9b2ecc3dd70db22c62/node_modules/next/dist/server/lib/router-utils/instrumentation-node-extensions.js:93:74
    at AsyncLocalStorage.run (node:internal/async_local_storage/async_context_frame:63:14)

[pablodecm]

Tried again, made sure that no cache was used and tested with workflow@4.2.0-beta.75-a7110de from the fix branch tarball — the globalThis singleton fix for AsyncLocalStorage is confirmed present in @workflow/core, but the issue still reproduces on Vercel deployments in vercel hence no luck so far.

@VaguelySerious vercel's builder/runtime may inject its own copy of @workflow/core at build time or maybe this was just not the cause?

[pablodecm]

Actually disregard my previous comments please @VaguelySerious , seems after forcing the ignore of the vercel cache of the deployment all seems to work well, so the fix seems to work. Caching was meddling with my testing.

[pablodecm]

We are actually now getting it new fresh production deployments with frozen workflow@4.2.0-beta.72 so I think there is some factor to this that either is vercel-specific or affected by caching, is a bit puzzling. Any pointer will be welcome.

[VaguelySerious]

@pablodecm Glad to hear this fixes it, aside from the caching issue. We'll release a version with this soon.

For the caching, just checking: you only have the one workflow package in your package.json, and you don't explicitly install any other workflow-related packages, right? Is there anything special about your cache settings in any part of your deployment process? We'll take a close look

[pablodecm]

Thanks for the response @VaguelySerious

Yes only we have workflow (and @workflow/typescript-plugin as dev dep but I doubt that affects). Is a turborepo in vercel but the only one that has the workflow dep is our main app.

I do have a few pnpm overrides to remove fully unused deps but I tested them:

      "workflow>@workflow/astro": "-",
      "workflow>@workflow/nest": "-",
      "workflow>@workflow/nitro": "-",
      "workflow>@workflow/nuxt": "-",
      "workflow>@workflow/rollup": "-",
      "workflow>@workflow/sveltekit": "-",
      "workflow>@workflow/cli": "-",

The weird behaviour observed is the following even with the version that worked until today (workflow@4.2.0-beta.72):

• We do a new deployment to production with that version and I get that error
• We do a redeploy (not using the build cache) and it works
• We also have a deployment with exactly the same commit in staging and it does work fine

We experience a similar thing when testing your patched version (first it did not work, redeployed version worked).

This what leads me to believe me that is either a cache issue or something on the vercel side, any guesses to what it could be?

Our end goal is able to release to production with confidence, specially if we do not change the package version, i.e. if it works in staging/preview we expect to work in production but this deployment-specific issue making us having to do a rolling release and smoke test for all releases.

Any good guesses/hunches to what could be going on would be appreciated.

[VaguelySerious]

@pablodecm I dug deeper on this, and we don't have a solid way of reproducing this issue on any version, having test every version between .72 and .76. The attached PR could potentially fix the issue when it does occur, and the only validation we have is that an agent can synthetically reproduce it by breaking the cache/bundling.

The underlying issue seems to be with build caching. Unclear as of yet if it only happens with Turbopack. I'll loop in some more experts on that

[VaguelySerious]

@pablodecm We're merging/releasing the potential fix for now and closing the issue. Please do re-open if you're seeing any caching issues or similar errors

[pablodecm]

@VaguelySerious and team thanks a lot for the investigation and the fix.

To err on the safe side, we will do rolling production deployments and keep an for the next few ones until the build cache to make sure we do not break production.

PS: congratulations to the team on the continuous improvements to this package and infra, we have been users since almost the beginning and now it powers all our workflow needs which are quite a few.