Variables defined in function node are not holding values on 0.198.2

Description of the issue/error/question

variables defined in function node are not holding values on 0.198.2

What is the error message (if any)?

variables defined in the function node are not holding values and are retuning null when called from other nodes.


Share the output returned by the last node


Information on your n8n setup

  • n8n version: 0.198.2
  • Database you’re using (default: SQLite): Postgres 14
  • Running n8n with the execution process [own(default), main]: own
  • Running n8n via [Docker, npm,, desktop app]: Docker

I’m not sure I’ve tried mutating data of another node from a Function node. I can confirm using an expression in a Set node still works:

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

Double checked I’m on 0.198.2 and the output when using the workflow I posted:

1 Like

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?

Any other alternatives possible without using data store such as redis?

n8n doesn’t have a proper built-in storage option unfortunately, so external databases would usually be my first choice for such use cases.

Though perhaps @sirdavidoff can clarify if the change you have noticed was indeed intended or not.

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/[email protected] · GitHub
File: packages/core/src/NodeExecuteFunctions.ts
Line No: 1349

executionData = executionData.json ? [executionData] : [{ json: executionData as IDataObject }];

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 :frowning:. 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.

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. :slight_smile:

A friendly hello to all,

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.

1 Like

Hi @MutedJam,
any update from the team on this? any workaround or fix planned up?

Hey @Roney_Dsilva,

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:

1 Like

Hey @Roney_Dsilva,

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.

1 Like

Is there any update on this yet? Any discussion or consideration by the team to bring back the feature?

No, sorry that it definitely not coming back as it should never have worked in the first place. So it was a bug and not a feature.

Depending on your exact need static data is a possible solution moving forward:


Thanks @jan , Just tested the static data in the Code node, and it works for my use case.