Repository: next.js
Issue: pages router global _error.tsx is triggered instead of app router global-error.tsx when force-static page used
Labels: Runtime,Pages Router,linear: next,Module Resolution

### Link to the code that reproduces this issue

https://github.com/holubiev/nextjs-global-error-reproduction-app

### To Reproduce

1. Build production app and start it: `yarn build` && `yarn start`
2. Visit some of [domain]/[lang] dynamic route: _localhost:3000/example/en_
3. See browser renders page router __error.tsx_ page instead of app router _global-error.tsx_

### 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

```bash
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()` or `redirect()` 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 within `Error.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?