App Router: Application crashes with client-side exeption on dynamic import failure

[TxHawks]

Link to the code that reproduces this issue

https://github.com/Txhawks/missing-chunk-error

To Reproduce

The reproduction imports a Foo component using next/dynamic. When the network request to foo.js fails, the whole app comes down crashing.

1. Navigate to https://missing-chunk-error.vercel.app/
2. In the Network tab in the dev tools, block the request for 201.e0005a340046428d.js
3. Reload the page, which will result in a ChunkLoadError: Loading chunk 38 failed. client-side error.

This isn't limited to Vercel and can be reproduced locally with next build && next start as well.

Current vs. Expected behavior

As explained above, any failure in loading a component with next/dynamic causes an error that is entirely irrecoverable in the client, and which crashes the entire app. Even Doing something like this doesn't help:

'use client';

import dynamic from "next/dynamic";

let Foo: React.ComponentType = () => null;

try {
  const TempFoo = dynamic(() => import("./foo"), { ssr: false });
  Foo = TempFoo;
}
catch (e) {
  console.error(e);
}

export default function ComponentPicker() {
  return <Foo />;
}

Dynamic imports are susceptible to network flaws and causing of an irrecoverable client error for something like this makes applications extremely brittle.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000
  Available memory (MB): 65536
  Available CPU cores: 10
Binaries:
  Node: 20.10.0
  npm: 10.2.3
  Yarn: 1.22.19
  pnpm: 8.15.4
Relevant Packages:
  next: 14.2.0-canary.50 // Latest available version is detected (14.2.0-canary.50).
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.4.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

App Router, Dynamic imports (next/dynamic)

Which stage(s) are affected? (Select all that apply)

next start (local)

Additional context

I've seen #54008, and this does seem similar, but seems to not be the same. I tried against 13.5.5 which the issue mentions, and it fails in the same way there.

[TxHawks]

Looking at the call stack, it seems like the error comes from here:
https://github.com/webpack/webpack/blob/23c39437617d5ff8de4120911e728b0f56a5fed5/lib/web/JsonpChunkLoadingRuntimeModule.js#L177

And when stepping through the code, the last line I could get to was the setTimeout on line 201 here:
https://github.com/vercel/next.js/blob/canary/packages/next/src/shared/lib/loadable.shared-runtime.tsx#L196-L207

[Dwlad90]

Changing installedChunkData[1](error); to console.error(error); in https://github.com/webpack/webpack/blob/23c39437617d5ff8de4120911e728b0f56a5fed5/lib/web/JsonpChunkLoadingRuntimeModule.js#L193 seems to superficially fix the issue and blocking the chunk no longer causes the application to crash.

[john-subba]

while using next/dynamic
do u have this type of code with your file paths in page source?. while clicking view page source.

[TxHawks]

@john-subba I'm not sure what you're asking, but I think your issue might be different and related to #64386

[john-subba]

@TxHawks while using next/dynamic this appears in your page source. I mean to ask does this appear in your website page source too?.

While clicking view page source.

[TxHawks]

You can look at the reproduction code here: https://github.com/Txhawks/missing-chunk-error

And at a deployed version of it here: https://missing-chunk-error.vercel.app/

[pranavks]

We're facing the same. Got a lot of ChunkLoadErrors in Sentry. After the dynamic imports were removed they're gone. Waiting for a fix.

[dbstjddbwls]

Datadog Error Tracking is also talking about the same problem.

I'm using Next^14.2.5 and some users have the same problem even though there was no web deployment.

[studentIvan]

@pranavks we got the same on the high-load site. It's easy to reproduce this issue using the parsers like "Screaming Frog" with 25 or 35 threads (speed) + render javascript enabled. The pages will be visible in ~5 minutes as h1 -> length 0 (by sorting this column)

All of them have the error like this (this is a custom error boundary to show the error message and the isolated test server)

Not sure is it related to the main issue but it can't be fixed with the performance raise...

[studentIvan]

@TxHawks you are on the right way to solve this problem, the error itself comes from import(...) function call. You can add the wrapper around the import to silent this error and give at least the one more attempt to fetch it.

Here is my example for you, let me know if it helps
https://gist.github.com/studentIvan/bef906c83c4bf0d659d45207b70a3bc0