facebook/react · error · Error

Could not find the module "${id}" in the React Server Manife

Error message

Could not find the module "${id}" in the React Server Manifest. This is probably a bug in the React Server Components bundler.

What it means

Before a server function reference can be used, resolveServerReference splits the '#name' suffix off the id and looks the module up in the turbopack server manifest on the client. A miss means the client bundle's manifest predates the action — the id the server embedded is not known to this client compilation.

Source

Thrown at packages/react-server-dom-turbopack/src/client/ReactFlightClientConfigBundlerTurbopack.js:129

  id: ServerReferenceId,
): ClientReference<T> {
  let name = '';
  let resolvedModuleData = bundlerConfig[id];
  if (resolvedModuleData) {
    // The potentially aliased name.
    name = resolvedModuleData.name;
  } else {
    // We didn't find this specific export name but we might have the * export
    // which contains this name as well.
    // TODO: It's unfortunate that we now have to parse this string. We should
    // probably go back to encoding path and name separately on the client reference.
    const idx = id.lastIndexOf('#');
    if (idx !== -1) {
      name = id.slice(idx + 1);
      resolvedModuleData = bundlerConfig[id.slice(0, idx)];
    }
    if (!resolvedModuleData) {
      throw new Error(
        'Could not find the module "' +
          id +
          '" in the React Server Manifest. ' +
          'This is probably a bug in the React Server Components bundler.',
      );
    }
  }
  if (resolvedModuleData.async) {
    // If the module is marked as async in a Client Reference, we don't actually care.
    // What matters is whether the consumer wants to unwrap it or not.
    // For Server References, it is different because the consumer is completely internal
    // to the bundler. So instead of passing it to each reference we can mark it in the
    // manifest.
    return [
      resolvedModuleData.id,
      resolvedModuleData.chunks,
      name,
      1 /* async */,

View on GitHub (pinned to eafeac097b)

Solutions

  1. Hard-reload the client so the fresh manifest is loaded
  2. Restart the dev server so server and client manifests regenerate together
  3. Deploy server and client from a single build so action ids always match

Example fix

# before
# add new server action, browser tab still on old bundle -> call fails

# after
$ rm -rf .next && npm run dev   # then hard-reload the page (Cmd+Shift+R)
Defensive patterns

Strategy: validation

Validate before calling

import {bundlerConfig} from './turbopack-server-manifest';
function serverReferenceResolves(id) {
  const moduleId = id.slice(0, id.lastIndexOf('#')) || id;
  return Boolean(bundlerConfig[moduleId]);
}
if (!serverReferenceResolves(actionId)) {
  throw new Error('Server manifest stale; reload the client bundle');
}

Prevention

When it happens

Trigger: Calling a newly added or renamed server action from a stale client bundle (tab open across a redeploy, HMR that did not refresh the manifest), or a server/client manifest pair from different builds.

Common situations: Adding a server action and hot-reloading without a full page reload; rolling deploys where old client HTML calls new server actions; dev-server cache reuse.

Related errors


AI-assisted analysis of facebook/react@eafeac097b (2026-08-21). Data as JSON: /api/errors/22cfa2ad95453a3c. Report an issue: GitHub.