WebSocket Connection Fails for Node-RED UI via Ingress Proxy with Large Entity Count

[zachowj]

Problem/Motivation

Any part of the Node-RED UI that relies on the websocket connection—such as inject nodes, the debug panel, and input field autocomplete—becomes unusable for users who access the Node-RED UI through the ingress proxy and have a large number of entities and devices. This occurs because the ingress proxy has a default max message size of 4MB. However, when connecting directly to the Node-RED UI on port 1880, this isn't an issue since Node.js has a default max message size of 100 MB.

This is similar to the issue addressed in this supervisor API proxy fix: home-assistant/supervisor#4443.

Expected behavior

The Node-RED UI should function normally, allowing users to utilize inject nodes, the debug panel, autocomplete, and other websocket-reliant features, even with a large number of entities and devices.

Actual behavior

When accessing the Node-RED UI via the ingress proxy, the websocket connection between the UI and backend fails, making any part of the UI that relies on it (e.g., inject nodes, debug panel) unusable.

Steps to reproduce

1. Access Node-RED UI through Home Assistant using the ingress proxy.
2. Ensure the Home Assistant instance has a large number of entities and devices.
3. Attempt to use features like inject nodes or the debug panel.

Proposed changes

[github-actions]

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!

[zachowj]

still relevant

[github-actions]

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!

[zachowj]

still relevant

[frenck]

The default load handled on the nginx in between is already 512m (like just big). I suspect the buffering having issues with the nginx proxy in this case. I'll disable those to see how it goes.

../Frenck

[zachowj]

Disabling the proxy buffer had no effect.

When I initially investigated this, I created a simple package/node that accepts a number (representing the number of bytes) and sends a message using the Node-RED WebSocket to the client. The message size matches the specified byte count, with a small addition for message syntax overhead.

From my testing, the only way to transmit a message exceeding the default WebSocket max message size was to increase the limits on both the Home Assistant ingress proxy and the supervisor ingress proxy. While my notes confirm that increasing the supervisor ingress proxy limit alone did not work, I don't have a record of testing the HA ingress proxy individually before increasing both.

That's as far as I could explore the issue before I ran out of time.

The attached GIF demonstrates sending three messages of varying sizes: one ~1,000 bytes, one ~4.1 MB, and one exceeding the default max message size. When the largest message is sent, you can see the connection terminate and then re-establish. I recall encountering a "message too large" error from the supervisor proxy during testing, but I couldn't find this error in my notes.

Here’s the demo node I used to send back WebSocket messages. It can easily be uploaded via the palette manager's upload feature:

zachowj-hassio-igress-0.0.1.tar.gz

[github-actions]

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!

[zachowj]

still relevant