Odd issue comes and goes, apparently random? This going to sound a big crazy... but here is the scenario.
Set flow variable. Works
Change flow variable. Works
Change flow variable again. Fails. The new value is never set.
Does not seem to matter the flow is complex or not, but the more complex the flow the greater the frequency of occurrence.
Once this happens, I can run the same sequence above or flow that does similar and the flow variable never changes, it is almost like it becomes 'locked' or static. Deploy the flow still happens. Stopping and starting NR service does not seem to fix the issue.
I have do destroy the part of the flow and recreate it. This most of the time fixes the issue.
What is really odd is that it is so far impossible to recreate consistently. When I export and import the flow the problem disappears until it reappears. Removing and reinstalling NR does not eliminate the issue, it returns, so it fells like a code scope issue of some type.
Running NR 4.1.1 on Pi OS (latest) fully patched.
Is there any chance that someone else has experienced this flow variable freezing, I guess you would call it, as well?
How are you handling the variable? Just via change nodes? Using a function node?
Also, have you checked for async issues - where one part of the process sometimes changes the data before it has been processed "later" in your flow? Remember that, while we talk about "messages" and "message flow", that isn't really what happens. In reality a "message" is simply a bit of memory who's location is passed by reference to the next node. So async processes can certainly operate on that data out of sequence. Doesn't happen too often but it certainly can happen.
Typically a change node. And I am back tracking through the flows thinking the async scenario is likely. I have a number of flows that have parallel processing, the flow variables are not 'mutex' states, just reporting flags, so at least I avoid that scenario.
I also noticed that the 'context' view can suffer from update synchronization. I click on the refresh of course, and the value can be at times misleading as the flow continues.
My first advice would be to get rid of the flow variable and pass the value about in messages. The sort of problem that you are seeing shows exactly why flow and global context are best avoided.
If you don't want to do that then (assuming that this is a simple variable and not part of a structure in context) then find all the places that it is written and add debug nodes there which write the new value to the console as well as the debug pane. Then you can check that it is not being re-written somewhere, by looking back at the log.
Also check in the node red log that there are no errors.
I fully agree with Colin.
Clever people find solutions to problems which wise people avoid in the first place.
Use message properties instead of context variables.
Well, I may be rewriting the flow to avoid the context dependence.