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.
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
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.
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).
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.
