#5930·node-red

NODE-RED Crash because of: [error] Error: read ETIMEDOUT

Author: miaszhCreated Sep 8, 2026Updated Sep 8, 2026
Labelsneeds-info

Current Behavior

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.

Expected Behavior

No response

Steps To Reproduce

No response

Example flow

paste your flow here

Environment

  • Node-RED version:
  • Node.js version:
  • npm version:
  • Platform/OS:
  • Browser: