Hello!
Unlike was happening before 1.X upgrade, now if one of the values in a node returns a null value, the whole node fails.
I have the condition where this value can be null, and before the upgrade to 1.X, this was not a problem, even if I flag “Continue on fail”, the behavior won’t change.
What can I do? 
EDIT:
I found that like the message say, the issue comes only if the mentioned node is not executed.
In my case, it can happen, depending of the IF node before.
Thanks!
even if I flag “Continue on fail”, the behavior won’t change
Hi @GBOL, this does sound like a bug to me and I am very sorry for this 
. I’ll add this to our engineering backlog for a closer look.
As a workaround until I have feedback on this one, perhaps you want to make sure both your IF branches pass the same node in your workflow (which you can then reference without the error)?
For example like below:
Here I am routing both results through the “No Operation, do nothing” node and read from this node instead of my “B” node to avoid running into the problem, even when the “B” node won’t otherwise run.
Thank you @MutedJam
This haven’t worked in my case, I tried but none:
I eventually overcome this issue but setting “Always output” to all the nodes you see above, this of course made the IF node not necessary anymore, so I’ll try my conclusions if this behavior will become the new standard.
Of course this introduce something more to think about when design a workflow.
In my workflows, sometimes it’s not mandatory to have a value in a key, so every exception needs to be handled. I hope this will not be the default.
Hi @GBOL, so while it appears this was intentional to some extent (falling under the workflow failures due to expression errors umbrella) it appears we have underestimated the overall impact this very error might have.
So it very much looks like we will improve this, however, there is no ETA yet. So in order to avoid the headache that comes with this change, you might want to consider sticking to n8n version 0.236.3 until an update version letting you ignore this error is available (we’ll update this forum topic once this happens).
Hey @MutedJam thanks for your prompt reply.
I cannot downgrade anymore, so I’ll stay on 1.X waiting for news and applying workarounds.
I appreciate your approach, I know you guys are working hard.
I’ll stay tuned 
We’re running into this too on some of our workflows. In the previous version, we would have multiple branches going into one node and if one branch executed, it would continue executing.
Like @GBOL we have already upgraded to 1.x and can’t downgrade anymore. I’m subscribing though to stay updated for when this does have a resolution. Thanks!
Edit: Here is a simple example:
I’ve reported a bug report here Branching nodes that don't run cause error when referenced - ERROR: no data, execute “node-name” node first · Issue #6880 · n8n-io/n8n · GitHub
Hey @roemhildtg,
As mentioned just now on the GitHub issue and by MutedJam earlier in this thread this is not a bug as such and is intentional behaviour.
fyi regarding downgrading. You should be able to downgrade to version 0.236.3. That version got specifically released to make it possible for people to downgrade to if there are issues with v1. Will obviously cause problems if you added, for example, nodes to workflows which are only available in v1. Apart from that should old workflows work fine.
We have this problem as well, although it is intentional behaviour. It was no problem in previous versions and a null/empty object would be pushed if the node did not execute, which is often the case in IFs. Now that is not really possible anymore. And have to build more branches of the same flow nut with different links. Are you still going to address this or not?
Hey @timautomation,
As this was an intentional change I am not sure if there are plans to change it back but I suspect it will now stay as it is.
Adding in a voice here: this has caused issues in several of my workflows. In particular, any workflow that has multiple potential input paths that may or may not run has issues. Pagination is also harder with this behavior, because sometimes you need to conditionally reference a node that may not have run yet.
I know this is intended behavior, but what’s frustrating is that even accounting for a potentially blank variable doesn’t fix it.
Example 1
In the following workflow there are two possible triggers. If the Toggl node triggers the workflow, it will run Toggle Report1 which is then referenced later. If the Cron triggers the workflow, Toggl Report1 is not run.
I already account for this with the following expression:
{{$node[“Toggl Report1”].json[“data”][“cid”] ? “&client_ids=” + $node[“Toggl Report1”].json[“data”][“cid”] : “”}}
IE. If this value exists, input it. Otherwise, leave it out.
But running this causes an error. (It used to work just fine)
Example 2
Pagination is harder and less flexible with this behavior. In the following workflow, I wanted to reference the page info from the API call in the “Set cursor” node.
If it doesn’t exist, I set it to no cursor. If it does exist, I set it to the next cursor. But because this API call hasn’t run, it gives me an error.
Suggestion
Either output Undefined/null for nodes that haven’t run yet, or allow some sort of try/catch functionality where we can decide whether it should cause an error.
Also running into this issue after upgrading. We split destinations based on previous nodes, and then determine whether a node has been executed or not further in the flow.
If we could do a check like if($node_has_executed(“blah”)) { do x, othewise y } then this would solve the problem.
Seems odd we can’t check whether a node has been run or not, and is breaking a lot of things.
Oddly I don’t have this issue with pagination, What I would do is add another set node on the false branch and set your url then go from that set node into the Get Access token node and just use {{ $json.url }} and that will get you around it so something like this…
For Example one you could have multiple workflows or tweak the workflow to not call previous node if there is a chance of it not running. It is annoying but it can be worked around and once the current workflows are changed it won’t be an issue.
That could be a good solution to it, We did post the breaking changes before 1.0 was officially released to get some feedback on it. I will pop open an internal feature request for this but it would be quicker to rework the flow.
Yeah, I did end up coming with workarounds for both but I think that behavior is kind of unexpected and inconvenient. I didn’t catch it in the breaking changes which is my bad.
Same case for me 
Updated to v1 and 90% of my workflows broke because of this. Downgraded to 0.237.0 and will remain there possibly forever. 
I use this approach very much: in one expression look for 2 or more nodes output. The remaining value corresponds to the node that has been executed previously.
I do not understand why this has been deprecated, it is so useful in so many scenarios. It simplifies the workflows and avoids redundacy very much. I hope that in some future 1.x release this will be available again 
Example of use case:
Hi @pbdco, I am so sorry for the trouble.
Can you try running your workflow on [email protected] or later (moving your expression into a Set node (just before your current Switch node) with the Continue On Fail option enabled and confirm if you’re able to execute the Set node? These versions would contain a quick fix that should hopefully allow such expressions to work in the Set node.
In your actual Switch node you can then read the result coming from the Set node.
Adding my 2 cent here:
I don’t know if it is applicable for all the cases, but for me the solution was to set “Always output” in all the nodes that can or cannot output data.
Just discovered this new behaviour yesterday and was looking for a way to not be stuck in the past as @pbdco.
@MutedJam - does ternary conditions shouldn’t be a workaround instead of multiple set nodes ?
In my case I setup several ternary conditions to retrieve Ids from different paths and it seems to works well.
{{ $node["searchAccountId"].json["Id"]?$node["searchAccountId"].json["Id"]:$node["searchAccountName"].json["Id"]?$node["searchAccountId"].json["Id"]:$node["CreateAccount"].json["id"] }}
Could you confirm that it should work in those cases ?
EDIT: Finally it triggers the same behaviour as if the first node don’t run it can’t check others