Move unhandled rejection handling to shared path (#77997)
The conventional wisdom of Node.js and other runtimes is to treat
unhandled errors as fatal and exit the process.
But Next.js is not a generic JS runtime — it's a specialized runtime for
React Server Components.
Many unhandled rejections are due to the late-awaiting pattern for
prefetching data. In Next.js it's OK to call an async function without
immediately awaiting it, to start the request as soon as possible
without blocking unncessarily on the result. These can end up triggering
an "unhandledRejection" if it later turns out that the data is not
needed to render the page. Example:
```js
const promise = fetchData()
const shouldShow = await checkCondition()
if (shouldShow) {
return <Component promise={promise} />
}
```
In this example, `fetchData` is called immediately to start the request
as soon as possible, but if `shouldShow` is false, then it will be
discarded without unwrapping its result. If it errors, it will trigger
an "unhandledRejection" event.
Ideally, we would suppress these rejections completely without warning,
because we don't consider them real errors. But regardless of whether we
do or don't warn, we definitely shouldn't crash the entire process.
Even a "legit" unhandled error unrelated to prefetching shouldn't
prevent the rest of the page from rendering.
So, we intentionally override the default error handling behavior of the
outer JS runtime to be more forgiving.
---
This was already the behavior of Next.js for self-hosted deployments —
i.e. `next start` — but the rejection listeners were being installed in
a code path that does not run for other deployment targets, like Vercel.
So what this PR does is move the rejection handling code to a path
that's common to all deployement targets.
One possibly controversial aspect that is new to this PR is that it
removes all existing "unhandledRejection" handlers, before Next.js
installs its own. This is to override any handlers that exit the
process. Generally we think this is fine because it's unlikely that
Next.js will be deployed in such a way that it's sharing a process with
non-Next.js applications; however, if we get feedback to the contrary,
we'll figure out a strategy to deal with it.
