ERROR: No data found for item-index: "1" Item Index: 1 | In or underneath Parameter: Query Parameters > Parameter

[Dan_Ray]

Since the upgrade my http request node has changed behavior. Previously, it worked correctly, and actually I have several examples of using the same node in the same way to do the same thing, and they all worked correctly.

Their function is to call an api and retreive a file, and the file is identified by an integer at the end of the url. e.g. https://io.cloud.my_domain.net/api/file/10422

In previous nodes, which are all still working as before, I find the integers I want, and create an item for each one which arrive at the http request node. Previously, the node ran for each of the input items, and retreived one file for each item.

Now, it still works if there is only one input item. However, if there is 2 or more, I get the error:
ERROR: No data found for item-index: “1”
Under Details it shows this:
Item Index: 1 | In or underneath Parameter: Query Parameters > Parameter
Then it quotes the Query Parameters, which in my case are these:

[
{"name":"={{ $node[\"Start Code\"].json[\"docassembleQueryParam\"] }}","value":"={{ $node[\"Start Code\"].json[\"docassembleFileName\"] }}"},
{"name":"session","value":"={{ $node[\"Start Interview\"].json[\"session\"] }}"}
]

These show in green in the node (signifying that they have been successful in retrieving the data), including when viewing the error messages, and so does the header which includes an api key. These work correctly, as it would not be possible to have the http request work for one file if any of these weren’t correct.

The dataset I’m calling can be viewed in various other ways, and I can see that the files I’m trying to retrieve do all exist, and the integers are correct.

Normally, n8n nodes all run very nicely and they run for each input item. For some reason not this time.

Please share your workflow

Example output from previous node:

[
  {
    "cm_clientuid": "36d0fefa-b950-47e1-ab34-ef3a61ae5faf",
    "cm_litigationuid": "523c13a5-2768-464c-aa89-01dc4487edd2",
    "filename": "2021-01-01 Contract 1 - \"1735_Culham_Court_OC_SAUNA_002.pdf\"",
    "DAUrl": "https://io.my_domain.net/api/file/10407"
  },
  {
    "cm_clientuid": "36d0fefa-b950-47e1-ab34-ef3a61ae5faf",
    "cm_litigationuid": "523c13a5-2768-464c-aa89-01dc4487edd2",
    "filename": "2021-01-01 Terms and Conditions 1 - \"KLAFS_TermsConditions.pdf\"",
    "DAUrl": "https://io.cloud.my_domain.net/api/file/10408"
  },
  {
    "cm_clientuid": "36d0fefa-b950-47e1-ab34-ef3a61ae5faf",
    "cm_litigationuid": "523c13a5-2768-464c-aa89-01dc4487edd2",
    "filename": "2021-04-27 Invoice 15007261 - \"Klafs_Technical_Invoice_15007261.pdf\"",
    "DAUrl": "https://io.cloud.my_domain.net/api/file/10409"
  },
  {
    "cm_clientuid": "36d0fefa-b950-47e1-ab34-ef3a61ae5faf",
    "cm_litigationuid": "523c13a5-2768-464c-aa89-01dc4487edd2",
    "filename": "Messages Upload 1 - \"200818_HSBC_Complaint.pdf\"",
    "DAUrl": "https://io.cloud.my_domain.net/api/file/10414"
  }
]

DAUrl is the only data I’m using from these input items (in this node). It provides the url for the api, inlcuding the integer at the end.

I’d love some help to resolve this please, Thanks,
Dan

[MutedJam]

Hi @Dan_Ray, I suspect you might have been affected by the problem described here.

So your expression probably wasn’t working before either because your HTTP Request node receives multiple items, but references another node with less items.

n8n version 1 will throw an error rather than quietly returning an empty item in such cases.

A simple solution in most cases will be the use of an expression such as $("node name").item making use of item linking or another available expression from this list such as $("node name").first(0, 0).

[Dan_Ray]

Hi MJ, thanks. I picked this up from your answer today on another thread, and it does solve the problem. Would I be right in thinking that for the best experience of n8n, I actually should update all the old style references I have to the new style $(“node name”).item references?
Many thanks,
Dan

[MutedJam]

So you would not need to update all references, but it could make sense to review your workflows when you have a bit of time.

Seeing this reference may have been problematic even before the upgrade (if the number/order of items changes between nodes), there may be unintentional culprits in your older workflows.

Workflows created in recent versions of n8n would use $('node name').item.json... by default when using drag & drop to build your expressions.

My suggestion would here be to sort your workflow list by creation date, then look at the active workflows only, starting at the oldest workflow (at the bottom of the list).