But in the workflow that you provided i still don’t see TEST pushed into the CHECKED array. I need the CHECKED array of FLAGS node to be updated when items are pushed to it. which used to happen in 0.190, after update somehow this has stopped working
Hi all, tbh I am not sure if this was supposed to work in the first place. The updated documentation refers to the current node input and the output of other nodes only, so it wouldn’t suggest other node data can be manipulated.
Perhaps you could consider using another data store @Roney_Dsilva?
Unfortunately, external data store cannot be implemented for the workflow logic which we have implemented.
It was working fine till version 0.197.1 (for almost 4 months since we developed), but stopped working on 0.198.0.
We are suspecting its due to commit feat(Code Node): create Code node (#3965) · n8n-io/n8n@1db4fa2 · GitHub
File: packages/core/src/NodeExecuteFunctions.ts
Line No: 1349
As now the previous executionData is reused instead of creating a new instance of IDataObject on every workflow.
This is the exact issue we are facing, as we can see it runs fine on the first execution, but fails on every consequent execution as it uses the values/flags set from the previous execution.
Yes, it seems likely this is related to the introduction of the code node, but as said I am not sure whether this is expected or not . So let’s see what the product team says on this one. I’ll also flag this internally, at least this should have been communicated as a breaking change.
@MutedJam
We highly appreciate your support and your suggestion for using an external datastore, but sadly as @Roney_Dsilva explained, its just not possible to implement it in our workflow. For now, we have decided to downgrade our n8n to the last known working version.
But can we get some kind of a store object? Like, say $_GLOBAL or something that we can use across the workflow execution?
I am pretty sure this will be very helpful to us as well as others.
As @Roney_Dsilva explained above, previously, we were using a node called “FLAGS” for this purpose, as we noticed that the data of that node could be manipulated from anywhere and it would reflect anywhere else in the workflow.
Hi @MayurVirkar, I like the idea of such a global object very much, let’s see what the team says. For the time being, downgrading really sounds like the best solution to me.
Thanks @MutedJam
We really appreciate your efforts.
I really hope we get this feature or an alternate solution that works with the updated version of n8n very soon.
Coz we are kind of in a pickle here.
I didn’t know that this was possible before and I don’t think it’s a good idea to change the result of a node afterwards. I would find it at least difficult to know who changed the data. But to do it anyway is understandable.
I would also like to know what the execution log looks like. Does the node contain its original data or the data overwritten by another node (which is theoretically not true)?
I would also very much like to see a global variable. Until then I pull the data through with, e.g. via a merge node.
Without merge you also can’t make sure which node is executed first or if it has been executed at all.
Since this can get quite out of hand, I always try to avoid forks. Better to execute the code one by one and get information from the corresponding nodes via $node or similar.
It looks like it is being talked about internally and currently it looks like this change was intentional so our product team is currently thinking about if this should be added back in or not.
It could be that Static Data might be a solution for this one but a more stable option that you have more control over would be to implement an external datastore of some kind or the workflow could be updated to use one branch from the start node instead of 3 which would keep everything in line and you could use merge nodes when you wanted to reference the value again.
Hi @Jon ,
Sadly due to the complexity of our workflows we are unable to use an external data source.
Currently, we have downgraded all our n8n instances to 0.197.1
Looking back at several other topics, I see that others too were using the function/Set node in a similar fashion.
Could you please relay to the team that it’s a crucial feature that would be of great help in several use cases.
Below are the topics where similar use cases have been discussed, all of which are not working anymore after 0.198.2:
At the moment we are still waiting on confirmation on if this change will be reverted or if we start to look at other options to handle it in a future release.
. So let’s see what the product team says on this one. I’ll also flag this internally, at least this should have been communicated as a breaking change.