next.js icon indicating copy to clipboard operation
next.js copied to clipboard

Root Layout Errors not triggering global-error.tsx

Open sean-hale-dev opened this issue 2 years ago • 27 comments

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

sean-hale-dev avatar Sep 15 '23 23:09 sean-hale-dev

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

huozhi avatar Sep 16 '23 00:09 huozhi

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.

milovangudelj avatar Sep 21 '23 16:09 milovangudelj

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

schardev avatar Jan 17 '24 11:01 schardev

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 avatar Jan 17 '24 14:01 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').

milovangudelj avatar Jan 17 '24 15:01 milovangudelj

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

huozhi avatar Jan 17 '24 18:01 huozhi

.

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!

carlos-dubon avatar Feb 11 '24 04:02 carlos-dubon

global-error.tsx in css not applying why

chk7964 avatar Mar 07 '24 21:03 chk7964

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

CleanShot 2024-03-25 at 10 49 39

vinayraghu1 avatar Mar 25 '24 14:03 vinayraghu1

@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 avatar Mar 26 '24 10:03 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.

milovangudelj avatar Mar 26 '24 17:03 milovangudelj

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

npearson72 avatar Apr 28 '24 21:04 npearson72

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

wisdomstar94 avatar May 02 '24 04:05 wisdomstar94

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

bear30921 avatar Jun 03 '24 08:06 bear30921

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!

gustavotrapp avatar Jun 20 '24 18:06 gustavotrapp

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.

alvarlagerlof avatar Jun 24 '24 07:06 alvarlagerlof

Would be great to see this fixed!

budokans avatar Jun 27 '24 12:06 budokans

+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!

Kvintus avatar Jul 04 '24 11:07 Kvintus

same issue

next 14.2.5 react 18.3.1 react-dom 18.3.1

lanmingle avatar Aug 03 '24 17:08 lanmingle

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.

mitchellabrouwer avatar Aug 16 '24 07:08 mitchellabrouwer

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",

MathiasOxholm avatar Aug 20 '24 08:08 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",

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!

gnoyixiang avatar Aug 21 '24 06:08 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!

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

theogravity avatar Sep 25 '24 04:09 theogravity

+1

facing the same issue

next 14.2.5 react 18.3.1 react-dom 18.3.1

global-error.tsx does not render the content

svarup avatar Oct 02 '24 12:10 svarup

+1

Same issue

next 14.2.6 react 18.3.1 react-dom 18.3.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!

Thanhwebdev avatar Oct 07 '24 17:10 Thanhwebdev

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').

Same here.

Reset function work fine on error.tsx but on global-error.tsx an error is thrown: TypeError: Cannot read properties of null (reading 'get').

Looking at the call stack you see that Nextjs tries to access get on parallelRoutes variable that is null.

Skärmavbild 2024-10-18 kl  08 59 01

ludwighogstrom avatar Oct 18 '24 07:10 ludwighogstrom

I've updated my test repository to use [email protected] and it reliably renders all error boundaries (try it out). I don't know when the fix has been implemented (it's hard to pinpoint it given the sheer number of releases since v14.0.5-canary.62).

For anyone still having this issue try updating to the latest canary (pnpm add next@canary) or take a look at how I implemented error handling in the repository and see if you're doing something differently or in the wrong way.

And if after that you're still having trouble triggering and resetting error boundaries upvote this issue with a :+1: instead of commenting "+1 me too" to avoid clutter, unless you have new detailed information that could benefit the maintainers.

Peace :v:

milovangudelj avatar Oct 18 '24 10:10 milovangudelj

I'm on 15.0.1 and it's not working.

igshehata avatar Dec 26 '24 11:12 igshehata

any update ? i'm on 15.1.3, it's not working.

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!

Ives7 avatar Dec 28 '24 05:12 Ives7

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

github-actions[bot] avatar Feb 04 '25 12:02 github-actions[bot]