You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
NODE-RED Crash because of: [error] Error: read ETIMEDOUT #5930
Node-RED intermittently terminates because of an uncaught TLS socket timeout:
[red] Uncaught Exception:
Error: read ETIMEDOUT
at TLSWrap.onStreamRead (node:internal/stream_base_commons:216:20)
systemd[1]: nodered.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: nodered.service: Failed with result 'exit-code'.
Systemd then restarts Node-RED automatically.
This has occurred repeatedly, including at times when no system-wide network interruption, kernel error, or out-of-memory event was recorded.
Environment:
Node-RED 5.0.6
Node.js 22.23.2
Raspberry Pi 5, arm64
Debian 13 (trixie)
A custom uncaughtExceptionMonitor captured the exception, but the stack only contains the internal Node.js TLS call and does not identify which contributed node owns the socket.
The active flows contain several persistent TLS connections, including:
node-red-contrib-alexa-smart-home 0.4.68
node-red-contrib-alexa-remote2-applestrudel 5.1.1
node-red-contrib-telegrambot 19.0.2
WebhookRelay connections
Before at least one crash, node-red-contrib-alexa-smart-home logged MQTT reconnection attempts. At the time, that palette was using MQTT 4.3.8.
As a test, I manually replaced its nested MQTT dependency with MQTT 5.15.2. The palette connects successfully and Node-RED has not produced another crash report since that change, but the observation period is currently too short to confirm that this is the solution.
I understand that Node-RED cannot necessarily recover safely from an arbitrary uncaught exception. However, a transient network ETIMEDOUT should normally be handled by the contributed node or its network library as a connection error, followed by a controlled reconnect, rather than reaching the Node.js process as an uncaught exception.
I would appreciate help identifying which connection or contributed node is allowing this timeout to escape its error handling, and whether additional tracing can identify the owner of the TLS socket.
Activity
knolleary commentedon Sep 8, 2026
Not a lot we can do to help track this down; those aren't nodes I use day to day, so not going to be able to recreate here.