Root Layout Errors not triggering global-error.tsx

[sean-hale-dev]

Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/intelligent-cdn-qkq9jc?file=%2Fnext.config.js%3A4%2C2

To Reproduce

1. Start application in development mode
2. Navigate to index page
3. See that the contents of global-error.tsx are not being displayed

Current vs. Expected behavior

I expect that the error throw in the root layout of the page is caught by the global-error.tsx file and that global error boundary is rendered. Currently the application fails when running next build and the developer error boundary is displayed when using next dev.

Verify canary release

• [X] I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000
    Binaries:
      Node: 20.6.1
      npm: 9.8.1
      Yarn: N/A
      pnpm: 8.6.0
    Relevant Packages:
      next: 13.4.19
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: N/A
    Next.js Config:
      output: N/A

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

App Router, Routing (next/router, next/navigation, next/link)

Additional context

No response

_NEXT-1623

[huozhi]

The global-error boundary is supposed only display in prod not in dev, then you can discover the error with dev error overlay to fix it. Having error in root layout will cause all app/ pages build failed.

The case here I think we can support global-error to render with app not-found routes, so it will error even you hit a bad route

[milovangudelj]

This can probably be closed since the issue is tied to an expected, although not documented, behaviour.

But, while experimenting with error boundaries and not-found.tsx's api I found that sometimes, or I should say most of the time, global-error.tsx does not fire at all even in production... I just get the default client side exception UI.

Let me know whether this should be placed in a new issue or not.

Here's a reproduction repo: https://github.com/milovangudelj/tests And here's the deployed example: https://tests.milovangudelj.com

You can trigger an error by clicking on the little red buttons placed throughout the demo.

[schardev]

This seems to be fixed in 14.0.5-canary.53 (https://github.com/vercel/next.js/pull/60539)

[milovangudelj]

Thanks for the heads up! I'll update Next to 14.0.5-canary.53 in my tests repo and see if it works.

[milovangudelj]

Ok, I tested it and it reliably renders the global error boundary (try it out, the link is still valid). BUT, it is never able to recover from it.

When calling reset an error shows up in the console. Next tries to create the initial router state and at some point calls fillLazyItemsTillLeafWithHead which in turn calls parallelRoutes.get resulting in a classic TypeError: Cannot read properties of null (reading 'get').

[huozhi]

@milovangudelj thanks for checking the updates, we're looking into this error right now 🙏

[carlos-dubon]

.

Edit by maintainer bot: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote 👍 on the issue description or subscribe to the issue for updates. Thanks!

[chk7964]

global-error.tsx in css not applying why

[vinayraghu1]

Wanted to report that I am also not able to trigger the global-error file even in prod mode. Are there any restrictions as to file extensions like .js instead of .tsx. I get the below screen even when I have a global error file and am testing

[milovangudelj]

@vinayraghu1 no, there are no restrictions for the file extension. You can use whichever you prefer.

As for the error boundary not triggering, try to compare what you're doing with what I showcased in the example repo linked above. You should be able to reliably trigger it.

[milovangudelj]

global-error.tsx in css not applying why

@chk7964 that's not relevant to this issue. You can go to the official Next.js discord server to ask for help.

[npearson72]

I'm still seeing the error in 14.2.3

I added the following to the root layout:

  if (process.env.NEXT_PHASE !== 'phase-production-build') {
    throw new Error('Boom!!!!');
  }

Then performed the build.

Visiting any page throws an error but the global-error.tsx page is not presented. I get the following stack trace:

Error: An error occurred in the Server Components render. The specific message is omitted in production builds to avoid leaking sensitive details. A digest property is included on this error instance which may provide additional details about the nature of the error.

^ This one I expect

DOMException: Failed to execute 'appendChild' on 'Node': Only one element on document allowed.

DOMException: Failed to execute 'removeChild' on 'Node': The node to be removed is not a child of this node

Uncaught AggregateError

^ These appear to be legit bugs

[wisdomstar94]

I also have a phenomenon where "global-error.tsx" does not work even though I intentionally generate an error in "next 14.2.3".

[bear30921]

same issue next.js: 14.2.3 react.js: 18.3.1 node.js: 18.20.2 npm: 10.5.0

[gustavotrapp]

Same issue here: next: 14.1

Edit by maintainer bot: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote 👍 on the issue description or subscribe to the issue for updates. Thanks!

[alvarlagerlof]

For anyone stuck on this, until it is resolved: We were able to work around this by wrapping the entire app a route group, where the new root has no logic that can fail. This allowed use to have another error.tsx that can catch the errors.

[budokans]

Would be great to see this fixed!

[Kvintus]

+1

Edit by maintainer bot: Comment was automatically minimized because it was considered unhelpful. (If you think this was by mistake, let us know). Please only comment if it adds context to the issue. If you want to express that you have the same problem, use the upvote 👍 on the issue description or subscribe to the issue for updates. Thanks!

[lanmingle]

same issue

next 14.2.5 react 18.3.1 react-dom 18.3.1

[mitchellabrouwer]

me too, same dependencies: "next": "14.2.4", "react": "^18.3.1", "react-dom": "^18.3.1",

I have a global-error.tsx in my app folder, but when an error is thrown by a component in my root layout (e.g., Navbar), the global-error file is not rendered.

In development, I get an "Unhandled Runtime Error." In a production build, I just get a white screen on error.

[MathiasOxholm]

Same issue here, when doing a fetch in root layout that throws an error, I just get an empty white page. The html has id of "__next_error__" but doesn't trigger the global-error.tsx.

"next": "^14.2.5", "react": "^18.3.1", "react-dom": "^18.3.1",

[gnoyixiang]

Same issue here, when doing a fetch in root layout that throws an error, I just get an empty white page. The html has id of "next_error" but doesn't trigger the global-error.tsx.

"next": "^14.2.5", "react": "^18.3.1", "react-dom": "^18.3.1",

Hey I just tested it out that the global-error.tsx page is displayed on my end by creating a fresh project. On my actual project, I found out that the issue it was not displaying was because there was an unhandled error in the middleware. If you have also implemented a middleware, you should check it out too!

[theogravity]

Same issue here, when doing a fetch in root layout that throws an error, I just get an empty white page. The html has id of "next_error" but doesn't trigger the global-error.tsx. "next": "^14.2.5", "react": "^18.3.1", "react-dom": "^18.3.1",

Hey I just tested it out that the global-error.tsx page is displayed on my end by creating a fresh project. On my actual project, I found out that the issue it was not displaying was because there was an unhandled error in the middleware. If you have also implemented a middleware, you should check it out too!

What are you expected to do when an error is thrown in middleware?