Skip to content

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

Open

Description

@miaszh

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:

Activity

  1. knolleary commented on Sep 8, 2026

    @knolleary
    Member

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions