Open S200124 opened 3 years ago
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?
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.
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
@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 ...
--unhandled-rejections=warn
to launch-node-red?wontfix
and close it?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.
Hi, due to the last modifications in NodeJs version 15 (https://nodejs.org/en/blog/release/v15.0.0/#throw-on-unhandled-rejections-33021, https://github.com/nodejs/node/pull/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.