I must admit, I got caught out by this in the Change node recently.
I had a stream of messages coming in and wanted to append a value from each message into a context array.
The Change node had a rule configured to set
flow.list to the result of
And I would always end up with a 1-element array in
flow.list. This is because when the first message arrives at the node, it would evaluate
$flowContext("list") which is an asynchronous operation. This would allow the second message to start to be processed, which would again evaluate
$flowContext("list") at that point in time - which is before the first message had got to the part of updating
flow.list. The end result - each message got
flow.list before it had been updated by the previous message, so they all got an empty array, then they appended their value and saved it back.
It certainly caught me out for a while - and I'm meant to know how this stuff works.
If we were to make the Change node strictly sequential it would not be good for performance. But I do wonder if we should add an option to the node to enforce sequential processing - something that can be turned on for the occasional scenarios that need it.
That would not have helped in the original issue in this topic - where the work to update Context is done in a subsequent node.