Add and change default OnUnhandledRejection mode to `throw` to match Node.js

[mohd-akram]

Problem Statement

The default mode changed in Node.js to throw (raise an error unless 'unhandledRejection' hook is set) in Node.js 15. The current default in Sentry, warn, shows a confusing and outdated message.

Solution Brainstorm

To implement throw mode, check if the user had previously set an unhandledRejection handler. If they did, throw and exit, otherwise print the warning.

Additional Context

The current strict mode also does not behave like Node.js. It should not print the warning message, but rather exit immediately.

Priority

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.}

[linear-code]

JS-2606

[logaretm]

Thanks for the report, I would say this is not planned given that:

• we had a prior decision in #12266 around not changing the SDK’s fatal unhandled-rejection behavior
• changing it may break existing apps for some users
• you can set mode=strict on the integration to get this behavior

However I will ping @getsentry/team-javascript-sdks-server if this is something that should be re-discussed internally and considered for next major perhaps.

[mohd-akram]

From my reading of #12266, that is dealing with an entirely different issue.

changing it may break existing apps for some users

I saw that there is an upcoming v11, that's why I suggested it. The current behavior is many years out of date. Node.js's throw behavior is fairly conservative.

you can set mode=strict on the integration to get this behavior

As mentioned, this also does not behave like Node.js since it prints the warning when it shouldn't, although that is a separate issue.

[logaretm]

that is dealing with an entirely different issue.

I meant it as a precedent to being cautious about changing the fatal unhandled-rejection behavior

Node.js's throw behavior is fairly conservative [...]

Node's behavior is more nuanced as it throws only if there are no listeners for unhandledRejection. The very act of the SDK listening makes Node stop doing that default escalation.

So if we wanted to match Node's behavior, we likely couldn't just map this to the existing strict mode. We would need to emulate throw semantics more carefully:

• If there are any user or third-party unhandledRejection listeners, Sentry should not throw.
• If Sentry is the only unhandledRejection listener, Sentry would need to throw/exit after capturing.

That may be possible, but it means the SDK has to inspect listener state and distinguish its own listener from user/third-party listeners before deciding whether to exit. So it’s not just a default flip, but I agree it’s something we can consider for v11, which is why I’ll raise it internally.