WebSocket issues probably.
The root cause is potentially outside of Node-RED, and possibly due to several reasons, therefore identifying the precise cause of this issue, and fixing it, is always going to be difficult.
It is unlikely to be a bug, as the key software runs very nicely most of the time for the vast majority.
Node-RED runs as a service, and runs the main execution engine that loads, then runs, the flows. Inside Node-RED is a server that provides much of the backbone system via API calls.
The front end bit that we see, the editor, is a completely different program, running as JavaScript inside a browser. The two programs communicate, when required, over a WebSocket between the JS editor and the Node-RED server.
This link is used to uplift the nodes, flows, and other settings when the editor first starts, and this can be the first sign of problems if the editor startup fails to complete. Problems with the JavaScript environment can be a cause at this point, and that is all down to the browser.
Once the editor is up and running, the key time the WebSocket gets used is to push back edit changes using the ‘deploy’ button. This causes NR to stop running the changed flow, dispose of all in-flight messages, and then upload the new edited copy, then restart the flow.
The inject nodes, the debug nodes, and the node status message are also all connected via the WebSocket. Inject nodes send triggers back to the NR flow execution to start a new message, debug nodes receive output from the NR flow for display in the debug window, and the individual node status messages are updated as required.
The primary reason why all of this stops is due to a failure in the connection between the editor and the NR server. There are other reasons, mostly to do with the editor running in the browser JS environment.
WebSockets are wonderful things, but they can easily get overloaded. The Home Assistant WebSocket nodes all connect back to Home Assistant via another WebSocket, and it is well noted that there should be only one HA Server Configuration node. If, typically by importing lots of flows from other sources, there are multiple HA Server config nodes, then each sets up a similar WebSocket connection, and all pointing to the same HA connection. Overload happens. This can also happen by setting up, for example, an Event: all node without specifying a filter. In this case, the WebSocket between NR and HA pulls in everything from the HA Event Bus, which can be very busy indeed, and the WebSocket connection gets overloaded.
When the HA-NR WebSocket connection gets overloaded, so does everything else, since NR is now too busy dealing with that. At this point, the debug and inject nodes appear to stop working, because there is no active or only a very slow connection between the editor and Node-RED server.
Have you checked to see what other ‘servers’ (configuration nodes) you have running in Node-RED? Do you have too many HA servers, are they doing too much, is Node-RED itself doing too much? Remember, NR is a single thread execution, and if any one node holds the processor for any period of time, NR itself will freeze while the individual node is running.
