facebook/react · critical · 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

On the consumer side, server references (Server Actions) are resolved by id in the server-references manifest: the runtime parses the '#name' suffix off the id and looks up the module. If neither the exact id nor the module entry exists, React throws this bundler-bug message — the payload references a server action the consuming bundle has no manifest entry for.

Source

Thrown at packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js:136

  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. Clean rebuild and redeploy client and server from the exact same build
  2. Ensure the action's file carries 'use server' and is processed by the RSC plugin in both compilations
  3. Align framework and react-server-dom-webpack plugin versions across the repo
  4. Verify caches (CDN, service worker, build cache) are not serving a stale manifest
Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-flight: confirm the actions manifest contains every id you will reference.
function hasServerRef(serverManifest, id) {
  if (serverManifest[id]) return true;
  const idx = id.lastIndexOf('#');
  return idx !== -1 && Boolean(serverManifest[id.slice(0, idx)]);
}

Try / catch

try {
  await doThing(); // 'use server' function
} catch (e) {
  if (String(e.message).includes('React Server Manifest')) {
    // Deployed bundles are out of sync — surface a rebuild/redeploy instruction.
    return {error: 'Client and server builds mismatch. Redeploy both from the same build.'};
  }
  throw e;
}

Prevention

When it happens

Trigger: An RSC payload or SSR output references a server action id (e.g. '4211/app/actions#doThing') that is absent from the client-side server-references manifest; adding or renaming a 'use server' function without rebuilding both bundles; the client.node/client.edge SSR runtime resolving an action reference during render.

Common situations: Client and server bundles deployed from different builds (partial deploys, CDN caching an old manifest); stale Next.js build cache; an actions file not processed by the server-actions compiler plugin; monorepo version drift of the RSC plugin.

Related errors


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