Config node context and persistency after deployment

I’m seeing some strange behaviour when using context on a config node..

If I set a value in node context from custom configuration node using:
this.context().set("s", "Hello")

Then I can read the value back using this.context().get("s") as expected. But if I redeploy the flows, then this.context().get("s") will return undefined.

Everything works as expected if I use this.context().global.set("s", "Hello") and this.context().global.get("s") - even after redeploying flows

Is this expected behaviour? This seems to work for "non config" nodes even after redeployment of flows.

I believe it is.

this.context() refers to the 'instance' context of the Node (at least for a config node)
if a Config Node is redeployed, the instance is destroyed and recreated, during deploy.

The argument here, is why this.context survives for None Node Configs - so I see why its been asked

@Steve-Mcl ?

Not an area i have delved into. What I will say is it is very likely this is unnecessary.

When a (config) node is instantiated and has its own this so things to store can be stored in this.that or this.other.

If you modify the config node OR do a full deploy, then that is expected unless context is persistent. And if that is the idea, then you should be storing the value in a property that gets written to the flow.

1 Like

Thanks for the reply. That makes sense, but it just seemed inconsistent/odd that this works for "non config" nodes and global context, but not for config nodes.

Is there another way for me to store a value between redeploys? (other than storing in global context or asking all users to setup a persistent context store).

I'm implementing a protocol that requires me to increase an id every time the node reconnect, so I need a place to store this last id between redeployments (I dont need persistency between node-red restart).

You could implement your own "store" by updating a file from within your node's runtime.

Thats not a bad idea, that is probably the way I need to go, but it still seems like a bug that it's not consistent with how normal node context works.