I have a custom node which uses a number of websocket connections and streams.
when I use the Full Deploy button , my node and all other nodes restarts as intended. However, when I use Deploy Modified nodes only , I noticed a strange behaviour where I am getting data streams from the old node still.
When I debugged this I noted that even after the Deploy using Modified Nodes only option, the old config values seem to still linger along side the new config. It is as if I have two versions of the node running at the same time.
I would have expected that the modified node completely restarts similar to the Full Deploy option, that is references are dropped and node is reset.
Node-RED version: v2.1.4
Node.js version: v13.10.1
Note: I plan to upgrade!
any thoughts or information ?
We would probably have to look at the code to see what is happening. The first thing to ask though is whether you understand the different parts of a node's runtime and which bits get run when? It isn't necessarily all that obvious until you've thought it through. Kept catching me out on more complex nodes which is why I took the time to de-structure my nodes to make it more obvious to me and to simplify parts of the structure.
@TotallyInformation what would be an example of those runtime internals that I need to consider when I use the Deploy Modified nodes only button ? In other words, what is actually happening differently than a Full Deploy ? I dont have knowledge of that
You need to understand that:
There is code outside the
module.exports which is run when the node is first imported by Node-RED. Any variables and function stay in memory but are not accessible outside your module.
The exported code is also run when the node is imported and it is passed the
RED object. It calls the registration function.
The registration function is called each time an actual instance of your node is added to a flow.
It actually creates the node instance using
RED.nodes.createNode and only after that call do you get a meaningful
this object that represents the instance of the node.
config object that contains the deployed variables from the Editor is passed to this function and you will want to apply the config properties to
this so that they are on each instance.
This function also contains the functions for handling incoming messages to your node instance and, if needed, a
close function for tidying up on re-deployment or removal of the instance.
input event handler is called each time a message is "sent" to your node instance. As the function is defined within (3), it inherits 3's
As you can see, there is considerable depth of embedding of functions within each other and it can be hard to understand each context.
That is why I de-construct my nodes to make the divisions easier to parse. You can find an example in my GitHub
node-red-experimental-nodes repo, check out the
new-node-template folder. While that structure is certainly more complex than needed for really simple nodes, as your node increases in complexity, it helps keep logical separation between the various moving parts.