I'm currently writing a node that has to emit an error under certain circumstances (not as part of handling an input message). For this I'm using the node.error() function passing in an error message and as second argument an object with details of the error. I observed that catching the error with a catch node didn't work, the error was always only logged to the debug sidebar and the console. Then I realized that this happens only during early node start, i.e. when the flow is still being deployed, because when I delayed calling the error() function by e.g. 2s, catching the error with the catch node worked. I assume that the problem happens because at the time I emit the error (without delay), the flow is not completely deployed and the catch node is possibly not yet started.
So my question is: is there a possibility that a node is informed when the flow is completely deployed in order to know when the error() function can be called? I don't want to utilize above described delay, this sounds like a workaround which might also not work in all situations (e.g. when deploying the flow takes even longer than the delay time) and I also have situations where I emit the error anyway at a later time, so the delay would be unnecessary in this case.
I have run into that a couple of times as well and wished that there was an event like flow started.
There are a few things to consider here:
should this event be on a flow basis or also global?
What about configuration nodes?
How to deal with nodes that do asynchronous things in their constructor?
What about partial deploys?
I guess a solution to this would be to have a done callback in the constructor (or as an argument for RED.nodes.createNode) and then two events flow started and all flows started, which fire only once if that particular node has been redeployed.
Yes, that makes sense. If the Node-RED runtime does not know when the nodes have finished initialization, it cannot provide the information, when flow deployment has completed. Maybe something like you proposed will be implemented in future.
what does "finished initialisation" actually mean ? If the node is one that sets up links to a remote database for example then is it finished when it starts to try to connect ? only when it has a successful connection ? If it doesn't connect correctly and times out then has it "initialised" (as the flow won't work at that point)... Do we block the whole flow from starting waiting for a node to connect to something that doesn't exist ?
I view that similarly to the done callback in the closing of the node.
It is the responsibility of the node developer to postpone calling done in an asynchronous part of the code only if absolutely necessary. Furthermore, there should be a timeout like in the closing of a node.
This means that one should NOT use this to wait for establishing a connection to a remote database.
However, knowing that now all essential node constructors have been called, one could for example establishing a connection to a remote database after the flow started event, meaning that if the connection is then established, it is ensured that a status or catch node can be notified.
and indeed we do have nodes-started event that is called when all constructors have been called... but as we know that doesn't mean they are all running at that point as they all start asynchronously.
A similar issue arises at startup when a node displays its status before a status node is ready to receive it. This can mean that a flow that should be triggered by that status message will not start or that a dashboard item showing the node status may not be correct. The only obvious remedy seems to be giving priority to the status and catch nodes when the flow is deployed, and I don't know where that stands.
