Cannot reference previous node output when using Merge

Questions
1

Can someone tell me why I cannot reference the “config” node’s value like I do in the “output” node? It’s undefined, but I would expect it not to be.

Using .first() works, but it feels off. Thanks.

Edit: had trouble including my workflow example due to Discourse input problem - switched to Markdown.

2

This behavior and the solution are described in the official documentation and community answers:

  • “You can avoid .item by using .first(), .last() or .all()[index] instead. They require you to know the position of the item that you’re targeting within the target node’s output items.”
    Item linking errors | n8n Docs

  • “If, for any other reason, you are only interested in the first item… if the thread that links output items back to their source items is broken or ambiguous, and you cannot use $item.”
    Can’t understand .first()

So, while it may feel “off,” using .first() or .last() is the correct and necessary approach in these situations due to how n8n’s item linking works after merges and branches.

3

Well, the doc says

When using .item, n8n displays an error when:

  • The thread is broken
  • The thread points to more than one item in the previous node (as it’s unclear which one to use)

I don’t get any error when running the workflow, just get an undefined which is not the same behavior. This happens silently. I would love an error actually. I understand I can use .first(), it works, it just feels unintuitive.

Also on this page in the doc it is said

$("<node-name>").item - The linked item. This is the item in the specified node used to produce the current item. Refer to Item linking for more information on item linking.

The important part being

This is the item in the specified node used to produce the current item

So it’s saying that .item that is being dereferenced on $("<node-name>") is the item used to produce the current item (the item whose config/setting page contains such an expression).

In this case, it seems to me, that since in “merge1” the 1st branch is chosen, the item that is being passed along this “route” is considered to be such an item (one that was used to produce the current item). The other branch’s item (which was “ignored”, but triggered still) is not considered to be such an item.

Which is fine I guess, it just feels off. I’m trying to build intuition for this case. Any explanation that is more than what is said in the docs is welcome. I read it. No bueno :slight_smile:

4

You are right, I have a case where I receive the error(not silently), just when the node is not executed and I can see the “undefined” why/where occurs.

Ex: I merge 2 items, but only one branch has executed. And the undefined item triggers the error since the linking doesn’t exists.

2 Likes