Hello,
I have a flow that start with a MQTT subscribe node.
After receiving the 1st payload, I save it in a flow context variable. Then the flow continues and eventually I reuse the (flow context) variable to write some data.
It looks like that if I receive 2nd payload (new messages on the MQTT subscribe node) when the previous instance of the running flow (dealing with the 1st payload) in not completed the flow context variable saved in the 1st running instance of the running flow, it can be overwritten by the 2nd payload.
It appears that the scope of the flow context variable in not limited to the "running" flow but to all instances of the same flow running at the same time. Is this analysis correct?
I tried the deep copy, it doesn't change the behaviour.
I hope my question is clear 
Thanks for the feedback.
This is the issue people hit when using flow and context unnecessarily (not saying that is what you are doing here - as you havent shared a minimal demo flow)
The best solution (where possible) is to pass the data in the msg and avoid context altogether.
As for copying/cloning, it depends what & where and when you do it (without seeing your flow it is hard so say).
If you are in a function node, use RED.util.cloneMessage
const copy = RED.util.cloneMessage(msg);
flow.set("lastPayload", copy.payload)
return msg;
No offense. This is probably what I do
I am saving the payload in the flow context in a change node.
I have learnt my lesson 
so I avoid global context as much as I can. I thought, apparently, wrongly that flow context was limited to an instance of the flow and not "wider" than that.
In my case, save to msg.something should be working. I take that "msg" is really limited to the running instance.
If you have to use context, you can avoid the context issue if you save the context with a unique name. So you could use the _msgid as part of the context name, as the _msgid will be the same through the running flow. Just remember to delete the context at the end of the flow or your memory will fill up.
e.g set.flow ("name" + msg._msgid, msg.payload) and at end flow.set("name" + msg._msgid, undefined) to delete.
Not sure I was being 100% clear - so just in case - when i say "context" I mean global context, flow context, local context - all context.
If you are using (ANY) context then no, you are not being "PURE" and you are seeing the issues you describe.
As soon as you save to context you have the issue of quick successive messages affecting the context (flow context in this case) mid flight.
There are work arounds (like mutexes and guards and flags etc) BUT the only way to be PURE is to work exclusively on the msg object (IE no global context, no flow context, no context)
Flow context applies to the editor tab. All nodes in that tab access the same flow context.
As Steve suggests this may well be an inappropriate use of context. After the MQTT In node copy the data you want to msg.myData (or some other more meaningful name) and then it should stay with that message down the wires and you can pick it up again when you want it.
Thank you for your answers. I’ll go with the msg.mqttpayload or equivalent. It should work as I am not tweaking with the entire message in the flow.
Saving to flow context is easy. But bad
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
