pages router global _error.tsx is triggered instead of app router global-error.tsx when force-static page used #69574
Labels
bug
Issue was opened via the bug report template.
Documentation
Related to Next.js' official documentation.
linear: next
Confirmed issue that is tracked by the Next.js team.
Module Resolution
Module resolution (CJS / ESM, module resolving)
Pages Router
Related to Pages Router.
Runtime
Related to Node.js or Edge Runtime with Next.js.
Link to the code that reproduces this issue
https://github.com/holubiev/nextjs-global-error-reproduction-app
To Reproduce
yarn build
&&yarn start
Current vs. Expected behavior
Current Behavior:
When using the app directory in Next.js with an app router and defining a static page using
export const dynamic = 'force-static'
in page.tsx, any error thrown on this page is unexpectedly handled by the Page Router's global error handler (_error.tsx), instead of being caught by the App Router's global error handler (global-error.tsx
). This behavior is inconsistent with expectations, as the error handling seems to cross over between different routing mechanisms (App Router and Page Router), which is not documented anywhere in the Next.js documentation.Expected Behavior:
When an error is thrown on a page using the App Router in the app directory, particularly with a static page (force-static), it should be handled by the App Router's designated global error handler (global-error.tsx). The Page Router's global error handler (_error.tsx) should not be triggered at all, ensuring that error handling is correctly scoped to the routing mechanism in use. The documentation should clearly mention how force-static pages handle errors, specifically when using the App Router.
This unexpected behavior leads to confusion and makes error handling inconsistent when using the App Router with statically generated pages.
Provide environment information
Operating System: Platform: darwin Arch: x64 Version: Darwin Kernel Version 22.6.0: Mon Jun 24 01:25:37 PDT 2024; root:xnu-8796.141.3.706.2~1/RELEASE_X86_64 Available memory (MB): 8192 Available CPU cores: 4 Binaries: Node: 18.19.1 npm: 10.2.4 Yarn: 1.22.22 pnpm: 9.9.0 Relevant Packages: next: 15.0.0-canary.138 // Latest available version is detected (15.0.0-canary.138). eslint-config-next: N/A react: 19.0.0-rc-7771d3a7-20240827 react-dom: 19.0.0-rc-7771d3a7-20240827 typescript: 5.3.3 Next.js Config: output: N/A
Which area(s) are affected? (Select all that apply)
Documentation, Module Resolution, Pages Router, Runtime
Which stage(s) are affected? (Select all that apply)
next start (local)
Additional context
Our use case requires throwing errors from force-static server components and handling these errors directly in the server environment. This is necessary because certain errors require server-side actions, such as performing a server redirect or returning a specific status code on the response page. When using
force-static
server component pages, we must ensure that static HTML is not generated and stored on disk, as this could lead to unnecessary storage usage for pages that are supposed to handle errors dynamically.Functions like
notFound()
orredirect()
do not address our needs in this scenario because they generate static HTML, which is contrary to our goal of preventing static page generation for error cases. Currently, the Page Router's_error.tsx
page provides a workaround by allowing server-side redirects withinError.getInitialProps
. However, it is unclear whether this behavior will continue to be supported in future versions of Next.js, as it is not documented.Our primary concern is whether Next.js will continue to support handling errors from React Server Components (RSCs) in a server-side context in Next.js 15. This is particularly important for cases where error handling requires server logic, such as conditional redirects or dynamic response statuses. Is there a plan for Next.js to handle errors from force-static RSCs in the App Router in a way that aligns with these requirements?
The text was updated successfully, but these errors were encountered: