1.0.5 - docker n8nio:latest ERROR: No data found for item-index: "1" - There's no item index?

Describe the problem/error/question

Executions of my workflow (n8n and traefik auto updating) have been running fine and then the stable release has updated last night to 1.0.5 and then the workflow this morning fails. All the visible items in the ‘Set’ node appear to be present and translated ok.

What is the error message (if any)?

ERROR: No data found for item-index: “1”

Please share your workflow

I’ve pasted it … but it’s not showing ??

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 1.0.5
  • Database (default: SQLite): SQLite
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
  • Operating system: Redhat 7.9 with latest Docker

Ok I figured out the issue … but seriously guys this migration change is really bit of nightmare breaking change caused by me using the UI to pick an output a previous node.

I’ve changed the reference in the SetConfig node from

{{ $node["SSH Test connectivity"].json["stdout"] }} staging (the wild test zone)


{{ $('SSH Test connectivity').item.json["stdout"] }}  staging (the wild test zone)

It’s the brackets for the node reference… and it’s changed to a single quote and removing the node stuff … a bit of a hacky change … note I’ve updated the To since editing


Hi @0101binary0101, glad to hear you figured it out, thanks so much for sharing your solution!

It appears your SSH Test connectivity node will only return one item (with index 0), whereas your dockerImages node passed on multiple items (with indices 0, 1, 2 etc.) to your SetConfig node throwing the error.

A legacy expression of $node["SSH Test connectivity"].json["stdout"] would try to match the items from your SSH Test connectivity node based on their index. This works for the first item with index 0 but would of course fail for subsequent items.

I would have expected this matching to fail for earlier versions of n8n as well, but I suspect this was a previously silent error that might have gone unnoticed. I am very sorry for the irritation this has caused.

1 Like

I’m quite worried looking at this question. May i ask if the change in the way other nodes are referred to from:

{{ $node["SSH Test connectivity"].json["stdout"] }}


{{ $('SSH Test connectivity').item.json["stdout"] }}

I’m talking about the change in type of brackets and the order of the terms,
Will it now be necessary to update all the working nodes I’m using?
(If it’s necessary to change them,… wow that’s bad news for me!)

Hey @Dan_Ray, these expressions would do different things.

The legacy expression $node["node name"] would reference items from a previous node by item index, whereas $('node name').item makes uses of item linking (previously called item pairing). Item pairing is not new functionality related to v1, item pairing was first introduced with n8n 0.180 around a year ago.

While I wouldn’t suggest using the old expressions anymore they should still work in principle and there is no need to replace them. In the case described in this thread they were simply referencing non-existent data, an error that might have previously gone unnoticed.

I think what stunned me was that the line was working fine under 0.236.3 ( The previous latest docker image version) and then appeared to break in 1.0.5,

The other confusing thing was that the translation of the Set node didn’t appear to show any issue in the debugging, the specific translation in question displayed the result in green as per below:

My other concern was that I have lots of these styles of $node[“node”].json[“var”] dotted around in various workflows… including IF decisions…

This expression preview would be shown for the first of your input items (with index 0), for which the expression would still work. It’s only failing for the second item (with item index 1) because your SSH Test connectivity node only produces a single item.

The expression itself still works, it just isn’t suitable for your specific data structure as I’ve tried to explain earlier. v1 throws an error now making you aware of this problem, whereas previous versions would seem to simply return an empty value for such items. The old behaviour seems to have caused such problems to be overlooked quite often which is no longer the case now.

1 Like

Don’t get me started on the expression preview :slight_smile: it gets frustrating when it handles multiple items from a batch split and only displays the last item :wink: even if I select the item from the input dropdown.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.