Next.js <> Turbopack Error - Module 52042 was instantiated because it was required from module 15861, but the module factory is not available.

[amansharrrma]

Summary

We have a landing page which only has static pages for now and we are deploying it using AWS CodePipeline which just builds the pages and puts it in a S3 bucket which is then served using AWS CloudFront.

These builds are appended into S3 and we don't delete the previous build modules for now.

We are facing a deployment Skew here. So lets say a user is on page and a new deployment is published, some of the users face this "Module X was instantiated because it was required from module Y, but the module factory is not available." error. I tried to reproduce this issue locally but couldn't with the condition that we have for the production deployment, though I was able to replicate this issue by replacing the requested chunk with some other chunk and got the same error.

But I'm not sure if this is what is happening in the production deployment as I tried changing the content in the local, rebuild it and then overwrite the current existing build such that the chunk hash changes to replicate the issue but it worked fine as it gets new updated page from the build.

I have already saw a few discussion related to this and checked for the wrong patterns that were mentioned and we aren't following any of them.

Additional information

No response

Example

No response

[juanfranciscocis]

---

This is deployment skew, and the fact that appending builds to S3 doesn't fix it is expected — the problem isn't missing chunk files, it's a stale HTML document.

What's happening: the user's browser holds an HTML/RSC payload from build A, which references a specific module graph. When they navigate client-side after build B ships, the router fetches a build-B RSC payload or chunk. Module IDs in Turbopack are content-derived and not stable across builds, so module 52042 in build B's graph is a different module than build A's runtime expects. Both files exist in S3 — they just describe incompatible graphs. That's why keeping old builds doesn't help.

Why local repro failed: overwriting the build locally also invalidates your dev/preview HTML, so the browser gets a consistent pair. The skew only shows up when the document is old and the fetch is new. To reproduce: load the page, run a new build with a changed component, deploy it, then click a client-side link on the still-open tab without reloading.

The actual fix — deploymentId:

// next.config.js
module.exports = {
  deploymentId: process.env.DEPLOYMENT_ID, // e.g. CODEBUILD_RESOLVED_SOURCE_VERSION
}

Set DEPLOYMENT_ID in CodeBuild to something unique per build. Next.js appends ?dpl=<id> to every asset and RSC request. When a build-A document requests a resource, the mismatched dpl causes the router to catch the failure and do a full page reload instead of throwing. This is exactly the mechanism Vercel uses for skew protection, and it works on any host — it's just a query param.

Things to check alongside it:

1. CloudFront must forward dpl as part of the cache key. If your cache policy strips query strings, deploymentId is a no-op. Add dpl to the query strings allowlist in your cache policy.
2. Don't cache HTML. /index.html and any route documents should be Cache-Control: no-cache, must-revalidate (or a very short TTL). /_next/static/* should be public, max-age=31536000, immutable. If CloudFront is serving stale HTML with a long TTL, users stay on the old graph long after deploy.
3. Invalidate HTML paths on deploy — /* for the document routes, or at minimum /index.html and /*.html. Static assets are immutable and don't need invalidation.
4. Keep appending old builds. Even with deploymentId, in-flight requests from build A need those chunks to exist. Prune on a lag (7–30 days), not immediately.

With deploymentId set, users on a stale tab get a clean reload instead of the module factory error.

[amansharrrma]

Thanks for the response it makes this issue much more clear to us.

We did have a deploymentId in the next config, but one of our developer found out that while fetching framer motion chunk the application used to make 2 chunk calls and cause a race condition which was eventually causing some issue(not sure what the issue was). Do you know if there is any other way to stop that dual fetch and race condition?

[Pleo2]

One important caveat for the proposed deploymentId fix: the full skew-protection handshake requires a Next.js server.

The documented mechanism has two different parts:

• ?dpl=<deploymentId> on static asset URLs is cache busting.
• Client navigation sends x-deployment-id, the Next.js server compares it, and the response carries x-nextjs-deployment-id; that mismatch is what triggers a hard navigation.

A pure S3/CloudFront static export has no Next.js server to perform the header comparison. Therefore deploymentId can help asset cache keys, but by itself it cannot guarantee the documented hard-reload behavior for an old tab. Next.js explicitly notes that it does not use the dpl query parameter for version-aware routing.

For this deployment model I would first verify whether the pipeline is publishing a true output: "export" directory or copying .next artifacts to S3. Then:

1. Publish /_next/static/* as immutable content and never overwrite or immediately delete old hashed assets.
2. Serve route HTML with no-cache or a short TTL and invalidate document paths during the atomic release switch.
3. Include the deployment identifier in the CloudFront cache key if it is configured.
4. Reproduce with an old open tab and inspect the failing request. Determine whether the mixed response is JavaScript, an RSC/navigation payload, or HTML; keeping old JS chunks does not protect a stable route-data URL that was overwritten by the new build.

If seamless recovery of old client navigations is a hard requirement, use a Next.js server with deploymentId support or version-aware routing that keeps each complete deployment addressable. For a static origin, a build marker checked by the client can trigger a deliberate reload, but that is application-level handling rather than the server-side Next.js skew protocol.

Official behavior: https://nextjs.org/docs/app/api-reference/config/next-config-js/deploymentId

[itzmitto]

This is version skew, and it's an expected side effect of code-splitting combined with rolling/appended deployments — not a Turbopack bug. It's officially documented under Next.js's Self-Hosting guide.

Here's the mechanism: a user has your page open from build N. That page's client runtime has a module graph tied to build N's chunk hashes. When something on that page triggers a lazy/dynamic import (route prefetch, a next/dynamic component, etc.) after build N+1 has been published, the runtime can end up trying to resolve a module ID against chunk files that no longer correspond to what it expects — hence "module X was instantiated... but the module factory is not available." You don't need to delete old build files to hit this; the mismatch is between the in-memory module map the open tab is using and whatever chunk actually gets served for a given path, not literally missing files. That's also why you couldn't reproduce it just by swapping a chunk locally — the trigger is a live tab surviving across a deploy boundary, not a static file-presence issue.

The fix Next.js ships for exactly this is the deploymentId config option (next.config.js):

module.exports = {
deploymentId: process.env.GIT_SHA, // or any per-build unique string
}

With this set, Next.js tags requests with the deployment ID and detects a mismatch between the client's ID and the server's. When it detects skew, it forces a hard navigation (full page reload) instead of attempting a broken client-side transition — so instead of crashing mid-navigation, the user just gets a normal reload onto the current build.

One caveat specific to your setup, called out directly in the docs: a deploymentId only prevents skew if requests are also routed consistently by deployment — Next.js itself doesn't do that routing (that's what Vercel's Skew Protection provides on their platform). On S3 + CloudFront you don't get that automatically, so deploymentId here mainly gives you the detect-and-hard-reload behavior rather than true request routing to a pinned deployment — but that's sufficient to eliminate this exact crash, since the failure mode you're describing is precisely "stale client tries a client-side transition against a newer server," and that's what triggers the reload.