next.js
next.js copied to clipboard
Root Layout Errors not triggering global-error.tsx
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
- Start application in development mode
- Navigate to index page
- See that the contents of
global-error.tsxare 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
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
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.
This seems to be fixed in 14.0.5-canary.53 (https://github.com/vercel/next.js/pull/60539)
Thanks for the heads up! I'll update Next to 14.0.5-canary.53 in my tests repo and see if it works.
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 thanks for checking the updates, we're looking into this error right now 🙏
.
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!
global-error.tsx in css not applying why
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
@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.
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.
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
I also have a phenomenon where "global-error.tsx" does not work even though I intentionally generate an error in "next 14.2.3".
same issue next.js: 14.2.3 react.js: 18.3.1 node.js: 18.20.2 npm: 10.5.0
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!
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.
Would be great to see this fixed!
+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!
same issue
next 14.2.5 react 18.3.1 react-dom 18.3.1
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.
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",
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!
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?
+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
+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!
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
resetan error shows up in the console. Next tries to create the initial router state and at some point callsfillLazyItemsTillLeafWithHeadwhich in turn callsparallelRoutes.getresulting in a classicTypeError: 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.
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:
I'm on 15.0.1 and it's not working.
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!
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.