Merge Node: Upstream node reference $('NodeName').item fails for non-first inputs

[ldaniel-jmz]

Bug Description

When using a Merge node (in "append" mode, for example), attempting to reference an upstream node's data using the $('NodeName').item expression fails for items that originated from the Merge node's second input (or subsequent inputs). The expression works correctly for items that originated from the Merge node's first input.
This behavior is a regression, as it was working correctly in n8n version 1.82.2.
The error typically shown is "ERROR: Can't determine which item to use" or a similar paired item resolution failure.

To Reproduce

To Reproduce:

1. Create a new workflow with the following nodes:
   • "Start" node.
   • Three "Set" nodes (e.g., Set variable_1, Set variable_2, Set variable_3).
     • Set variable_1 sets a field, e.g., variable_1 to 1234.
     • Set variable_2 sets a field, e.g., variable_2 to 2345.
     • Set variable_3 sets a field, e.g., variable_3 to 5678.
   • A "Merge" node.
     • Connect Set variable_1 to Input 1 of the Merge node.
     • Connect Set variable_2 to Input 2 of the Merge node.
     • Connect Set variable_3 to Input 3 of the Merge node.
     • Set Merge node "Mode" to "Append".
   • A final "Set" node (let's call it Output_Node) connected after the Merge node.
     • In Output_Node, create a field final_variable_1 with the expression: {{ $('Set variable_1').item.json.variable_1 }}
     • In Output_Node, create a field final_variable_2 with the expression: {{ $('Set variable_2').item.json.variable_2 }}
     • In Output_Node, create a field final_variable_3 with the expression: {{ $('Set variable_3').item.json.variable_3 }}
2. Execute the workflow.
3. Observe the output of the Output_Node.
   • For the item that originated from Set variable_1 (Merge Input 1), final_variable_1 will correctly show the value (e.g., 1234).
   • For the item that originated from Set variable_2 (Merge Input 2), final_variable_2 will fail with an error like "ERROR: Can't determine which item to use".
   • A similar failure will occur for final_variable_3.
     (Attached screenshots show the successful retrieval for final_variable_1 and the error "Can't determine which item to use" for final_variable_2 when inspecting the Output_Node results for the item originating from Set variable_2).

(Bug Test Workflow JSON):

{
  "name": "Bug Test Workflow",
  "nodes": [
    {
      "parameters": {
        "numberInputs": 3
      },
      "type": "n8n-nodes-base.merge",
      "typeVersion": 3.1,
      "position": [
        460,
        200
      ],
      "id": "92aad872-f96b-4785-a858-cf6ea48ef34c",
      "name": "Merge",
      "alwaysOutputData": true
    },
    {
      "parameters": {
        "assignments": {
          "assignments": [
            {
              "id": "63830a30-a4cc-4a66-9d01-8f0a058d4d43",
              "name": "variable_1",
              "value": "1234",
              "type": "string"
            }
          ]
        },
        "options": {}
      },
      "type": "n8n-nodes-base.set",
      "typeVersion": 3.4,
      "position": [
        160,
        0
      ],
      "id": "54eaa8ed-b3e8-4c59-af23-9c74d0f15f95",
      "name": "Set variable_1"
    },
    {
      "parameters": {
        "assignments": {
          "assignments": [
            {
              "id": "63830a30-a4cc-4a66-9d01-8f0a058d4d43",
              "name": "variable_2",
              "value": "2345",
              "type": "string"
            }
          ]
        },
        "options": {}
      },
      "type": "n8n-nodes-base.set",
      "typeVersion": 3.4,
      "position": [
        160,
        200
      ],
      "id": "d3ecaea8-e30c-4911-9adf-78e12df5a7ac",
      "name": "Set variable_2"
    },
    {
      "parameters": {
        "assignments": {
          "assignments": [
            {
              "id": "63830a30-a4cc-4a66-9d01-8f0a058d4d43",
              "name": "variable_3",
              "value": "3456",
              "type": "string"
            }
          ]
        },
        "options": {}
      },
      "type": "n8n-nodes-base.set",
      "typeVersion": 3.4,
      "position": [
        160,
        400
      ],
      "id": "2e65f7a3-d1f8-44b4-9199-671ba502dd2e",
      "name": "Set variable_3"
    },
    {
      "parameters": {
        "assignments": {
          "assignments": [
            {
              "id": "ed13172d-9bae-4b21-b168-577eee217e24",
              "name": "final_variable_1",
              "value": "={{ $('Set variable_1').item.json.variable_1 }}",
              "type": "string"
            },
            {
              "id": "7a92607d-d2f1-4b38-855f-4ec19b70f414",
              "name": "final_variable_2",
              "value": "={{ $('Set variable_2').item.json.variable_2 }}",
              "type": "string"
            },
            {
              "id": "89862e7d-0c44-4d6a-897e-a249c06f6346",
              "name": "final_variable_3",
              "value": "={{ $('Set variable_3').item.json.variable_3 }}",
              "type": "string"
            }
          ]
        },
        "options": {}
      },
      "type": "n8n-nodes-base.set",
      "typeVersion": 3.4,
      "position": [
        680,
        200
      ],
      "id": "898d35e4-42a7-4fad-8a01-3f0d6d966cab",
      "name": "Output"
    },
    {
      "parameters": {},
      "type": "n8n-nodes-base.manualTrigger",
      "typeVersion": 1,
      "position": [
        -140,
        200
      ],
      "id": "12501aa5-502f-4960-a44a-833d017a6eb7",
      "name": "Manual Trigger"
    }
  ],
  "pinData": {},
  "connections": {
    "Merge": {
      "main": [
        [
          {
            "node": "Output",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Set variable_1": {
      "main": [
        [
          {
            "node": "Merge",
            "type": "main",
            "index": 0
          }
        ]
      ]
    },
    "Set variable_2": {
      "main": [
        [
          {
            "node": "Merge",
            "type": "main",
            "index": 1
          }
        ]
      ]
    },
    "Set variable_3": {
      "main": [
        [
          {
            "node": "Merge",
            "type": "main",
            "index": 2
          }
        ]
      ]
    },
    "Manual Trigger": {
      "main": [
        [
          {
            "node": "Set variable_2",
            "type": "main",
            "index": 0
          }
        ]
      ]
    }
  },
  "active": false,
  "settings": {
    "executionOrder": "v1"
  },
  "versionId": "a3cd04e1-304b-4752-8989-d299c622495c",
  "meta": {
    "instanceId": "b7c05a8986e66772aa7af4004a000d6c3b16ca93d88d75938718485e254b5a15"
  },
  "id": "QNCbSmpQ2GNK0w3R",
  "tags": []
}

Expected behavior

The expressions {{ $('Set variable_2').item.json.variable_2 }} and {{ $('Set variable_3').item.json.variable_3 }} (and similar references to upstream nodes connected to non-first inputs of the Merge node) should correctly resolve and return the values set in their respective source nodes.
The behavior should be consistent for all items passing through the Merge node, regardless of which input they came from, and match the behavior of n8n v1.82.2.

Operating System

Ubuntu 22.04.5

n8n Version

1.94.1

Node.js Version

18.19.1

Database

PostgreSQL

Execution mode

queue

[Joffcom]

Hey @ldaniel-jmz,

We have created an internal ticket to look into this which we will be tracking as "GHC-2324"

[ldaniel-jmz]

Update: Workaround Found & Version Clarification

Workaround that works: Using .all()[0] instead of .item resolves the issue:

// Instead of: {{ $('Set variable_2').item.json.variable_2 }}
// Use: {{ $('Set variable_2').all()[0].json.variable_2 }}``

This workaround successfully retrieves the values from upstream nodes for all Merge inputs (1, 2, 3+).

Version clarification: I initially reported this worked in v1.82.2, but after further testing, I can confirm the issue also exists in v1.82.2. The problem appears to affect multiple versions, not just v1.94.1.

Expected behavior: The .item syntax should work without needing to use .all()[0], as it's designed to automatically resolve to the paired item in the current execution context.

Additional context:

• The issue specifically affects inputs 2+ of the Merge node
• Input 1 of the Merge node works correctly with .item syntax
• Data is available in the current item context ($json.variable_X works)
• Only the explicit node reference fails for non-first inputs
• This suggests the item pairing context is being lost/corrupted after the Merge operation for inputs 2+

[y-kovalchuk]

Same here, happened after updating to 1.94.
For now, we use _('Node').first().json as a workaround.

[ldaniel-jmz]

Same here, happened after updating to 1.94. For now, we use _('Node').first().json as a workaround.

The workaround that I'm using is {{ $('node_x').all()[0].json.variable_x }}

[gonpaul]

My specs: 1.94.1, self-hosted

After following the steps to reproduce it with manual trigger connected to the Set variable_1, I get the next hint in the Output node error message:

Referenced node is unexecuted
An expression references the node 'Set variable_2', but it hasn't been executed yet. Either change the expression, or re-wire your workflow to make sure that node executes first.

Hey, @ldaniel-jmz
If we also look at your attached Output node screenshots, two set nodes on the left were not executed, and therefore they don't have item fields.
I am a bit new to n8n, however, I guess that making sure all merge node inputs are executed before the node starts the work could be hard to maintain (think of recursive node traversal and executions) and lead to more unexpected errors.

To execute all the input nodes before the merge, we can go the next way:

Now, we get the expected output from the merge node:

So, the error points out that referencing back the merge node inputs is not allowed. It actually does not make any sense in this case, when we can use the merge node output directly.

[ldaniel-jmz]

Hi @gonpaul, thanks for taking the time to look into the issue. I appreciate your perspective, but I believe there might have been a slight misunderstanding of the core problem we're experiencing, even with the initial test workflow.

To clarify further, I've modified the test workflow to demonstrate that the problem persists even when we try to reference a node that executes before any branching and is therefore definitively executed for all items.

New Clarification Test Workflow:

Key Setup:

• Manual Trigger -> Set main_variable (sets main_variable_value) -> Switch
• The Switch directs the flow to Set variable_1, Set variable_2, or Set variable_3 (only one branch executes per run).
• These three nodes feed into a Merge node (mode "Append").
• An Output node after the Merge attempts to retrieve:
  • final_variable_X from Set variable_X (where X is the branch that executed).
  • main_variable from Set main_variable.

Observed Behavior (as seen in the attached screenshot of the Output node):
When the flow goes through, for example, Set variable_2 and then to the Merge node, in the Output node:

• The reference {{ $('Set variable_2').item.json.variable_2 }} fails (this is the original issue we discussed).
• More importantly for this clarification: the reference {{ $('Set main_variable').item.json.main_variable_value }} ALSO FAILS with "ERROR: Can't determine which item to use - execute node for more info".

This demonstrates that the issue isn't just about referencing a node from a parallel branch that "didn't execute," but that the ability to reference ANY previous node (even one that is a common ancestor and guaranteed to have executed) is compromised after the Merge node for items not coming from the Merge's first input.

Now, addressing your specific points:

"If we also look at your attached Output node screenshots, two set nodes on the left were not executed, and therefore they don't have item fields."

This is true for a specific execution down one branch. If the flow goes via Set variable_2, then Set variable_1 and Set variable_3 do not execute. However, the problem we're highlighting is that even the reference to the node that DID execute on that branch (e.g., Set variable_2) fails if that branch is not the first input to the Merge. And more importantly, as my new workflow shows, the reference to Set main_variable (which always executes) also fails.

"I guess that making sure all merge node inputs are executed before the node starts the work could be hard to maintain (think of recursive node traversal and executions) and lead to more unexpected errors."

I understand the point about the complexity of ensuring execution. However, the issue isn't whether all Merge inputs execute simultaneously (which isn't the case with a Switch before it, for example). It's that for the single item passing through a specific branch (e.g., the one through Set variable_2), the reference to that very Set variable_2 (or an earlier node like Set main_variable) breaks in the Output after the Merge. We are not trying to access data from branches that didn't execute for that particular item.

"So, the error points out that referencing back the merge node inputs is not allowed. It actually does not make any sense in this case, when we can use the merge node output directly."

The problem isn't just "referencing back the merge node inputs." The issue is that, for an item that has passed through the Merge, the ability to use the $('PreviousNodeName').item syntax to access data from any previous node (whether it's a direct input to the Merge or a much earlier node like Set main_variable) is affected if that item didn't enter the Merge via its first input.

While it's true that we could explicitly pass all necessary data through the branches and then access it with $json.data_name in the Output_Node, this doesn't address why the direct node referencing functionality ($('Node').item), which is a core feature of n8n and either worked more robustly/intuitively before or would be expected to work, is failing in this specific scenario. The purpose of $('Node').item is precisely to avoid having to manually pass all data through every node.

We hope this more specific test workflow and explanation help clarify the nature of the problem. It's not about accessing unexecuted nodes, but about a break in the ability to reference nodes that did execute (including common ancestors) when an item passes through the Merge node via its secondary or tertiary inputs.

[gonpaul]

@ldaniel-jmz
Oh, I see now. Thank you for such a detailed explanation

[ldaniel-jmz]

@ldaniel-jmz Oh, I see now. Thank you for such a detailed explanation

No problem! For now the workaround that I'm using is referencing the node using this sintax:
{{ $('node_x').all()[0].json.variable_x }}

Hope the n8n team fix this in futher releases!

[gonpaul]

@Joffcom Hey! I debugged the program and found the place where the error happens. Patched it locally. Should I open a draft pr with my improved implementation and write a test?

Structured the summary for the issue and added solution section.

What

Can't access any ancestor of executed upstream nodes when assigning parameters in Set node if the merge node precedes it.

When

the reference does not work when:

• non-first merge input is executed and flows through the merge node, while other merge inputs are unexecuted

Cause

When FunctionEvaluator.evaluate method from tournament lib uses a WorkflowDataProxy instance to get a node's values/variables (note: in this case, destination node should be executed down the flow branch, like Main variable set node), the graph traversal logic fails to work for non-first merge inputs, as the next if block triggered:

// inspected values: inputIndex = 1 (cause it's the second input for merge input, counted from 0)
// and sourceArray.length = 1 (cause two unexecuted merge node inputs are substracted being nulled out)
const inputIndex = currentPairedItem.input || 0;
if (inputIndex >= sourceArray.length) {
	if (sourceArray.length === 0) throw createNoConnectionError(destinationNodeName);
	throw createBranchNotFoundError(
		currentSource.previousNode,
		currentPairedItem.item,
		nodeBeforeLast,
	);
}

For this reason the graphical interface showed: Error: Can't determine which item to use

code snippet
at getPairedItem in WorfklowDataProxy.getDataProxy method. file: packages/workflow/src/WorkflowDataProxy

Solution

Branch out logic for items that can support multiple input nodes/connections.
For now, I was able to fix it by accounting for null items in the taskData.source object and conditionally update the inputIndex, if there are any null items (e.g., unexecuted nodes). My solution, however, only handles sourceArray of length 1, so in case when two input merge nodes from different upstream parent branches were executed, it should fail to work for all upstream nodes. I think I can fix it later as well.

code snippet

successful workflow execution

Though, I need to look at 1.82 version to see how it's done there not to reinvent the wheel.

Implications

It is possible that the same behavior could happen for all nodes qualified for PAIRED_ITEM_METHOD.ITEM capable of having multiple input connections because the same pairedItemMethod (look at workflow/src/WorkflowDataProxy line 1207) will be used.

Call stack for debugging

Started inspecting from SetV2.node.ts