Unexpected UnhandledPromiseRejection during runtime

[S200124]

Hi,
due to the last modifications in NodeJs version 15 (https://nodejs.org/en/blog/release/v15.0.0/#throw-on-unhandled-rejections-33021, nodejs/node#33021) now the default mode for unhandledRejection is changed to throw (from warn).

This sometimes causes some unexpected crash of Node-Red.

A temporary fix could be set an option to --unhandled-rejections=warn or use a version of NodeJs before 15.

[knolleary]

Hi - please try to use the issue template when raising issues.

Do you have any concrete instances of such a crash to share to help identify where changes are needed?

[S200124]

Hi @knolleary ,
thanks for your answer.
Sorry, this is my first time opening an issue. I will be more careful next time.

Yes, I have a running instances on Heroku, but unfortunately the only message I get in console is:

[red] Uncaught Exception:
UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "#Object".

npm ERR! code 1
npm ERR! path /app
npm ERR! command failed
npm ERR! command sh -c node packages/node_modules/node-red/red.js --userDir home

npm ERR! A complete log of this run can be found in:
npm ERR! /app/.npm/_logs/2021-01-22T13_41_42_037Z-debug.log

The running configuration is:
node-red: 1.2.5
node: 15.6.0
npm version: 7.4.0

Unfortunately, this happens totally random and in all the nodes, so I cannot detect better where is the problem.

[0rsa]

I saw this behaviour this week-end, testing nodejs 15.12.0 (node-red 1.2.9).

28 Mar 17:13:42 - [error] [yeelight-config:5f497ad3.1fd3a4] Error: read ECONNRESET
This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
Error: Network timeout, Yeelight not response
at Timeout._onTimeout (/root/.node-red/node_modules/yeelight2/index.js:230:29)
at listOnTimeout (node:internal/timers:557:17)
at processTimers (node:internal/timers:500:7)

I don't think it is a node-red issue, plugins developers have to catch exception properly.
By the way, this major change will reserve some bad surprises to users and developers in term of stability.
I reverted to nodejs 14.16.0

[Steve-Mcl]

@S200124 without further info on which node caused we cannot look into your particular concern.

@knolleary, @dceejay regarding the OPs suggestion of "set an option to --unhandled-rejections=warn", should we consider adding an unhandledRejection handler, disabled by default, but could be switched on via a setting in settings.js?

This might work for cases where an old contrib node works fine in (for example) nodejs12 but crashes node-red under v16 (& therefore holding a user back from upgrading node/node-red)?

Otherwise we should ...

1. make it clear that if you want to revert to the unsafe reject handling that the user uses CLI flag --unhandled-rejections=warn to launch-node-red?
2. mark this issue as wontfix and close it?

[dceejay]

It does have some appeal - but I'm not really sure it's a good idea to enable something like this that people may "just enable" to try to stop their flow crashing due to a bad node when really the node should be fixed.