Unhandled promise rejection exits Node.js 15+ process

Answer

Starting with Node.js 15, the default mode for unhandled promise rejections is throw, which turns the rejection into an uncaught exception and causes the process to exit unless you override it with the --unhandled-rejections flag.

Confirmed facts

• Node.js 14 default: warn (logs warning, continues).
• Node.js 15+ default: throw (exits on unhandled rejection).
• The flag accepts warn, throw, strict, none; strict behaves like throw but guarantees a non‑zero exit code.

Likely explanation for production services

Using the default throw can cause unexpected restarts or crashes in long‑running services, especially when running in clustered or worker‑thread setups where a single worker’s failure may take down the whole process. Keeping the older warn behavior (or handling rejections and using none) preserves availability but may hide bugs; strict still exits, only giving a guaranteed non‑zero status.

Steps to configure and verify

1. Check the installed version:

   node -v

2. If the version is >=15.0.0 and you want the Node.js 14‑like behavior, start the service with

   node --unhandled-rejections=warn your-app.js

   or handle all rejections and use --unhandled-rejections=none.
3. To verify the mode, run a minimal test script:

// test-rejection.js
Promise.reject(new Error('unhandled'));

Execute it with the same flags you plan to use in production:

node --unhandled-rejections=warn test-rejection.js   # should print a warning and exit with code 0
node test-rejection.js                                 # with default (>=15) will exit with non‑zero code

Observe whether the process prints only a warning and continues (exit code 0) or terminates with a non‑zero code.

Missing diagnostic detail

Does your deployment use cluster or worker_threads? If yes, the throw (or strict) mode will cause the whole process to exit when any worker encounters an unhandled rejection, making warn the safer choice. If you run a single‑process service without workers, you may consider strict to guarantee a non‑zero exit while still surfacing the rejection.