I feel like I in the past had been able to end a code node with a simple “return $input.all()”, but now I am returning this error? If I put it inside a json format I get something, but it’s not the right format.
What is the error message (if any)?
ERROR: Unknown top-level item key: index
Access the properties of an item under .json, e.g. item.json
Please share the workflow
(Please ignore the note. It’s not relevant)
Share the output returned by the last node
Information on your n8n setup
n8n version: 0.213.0
Database you’re using (default: SQLite): Aurora DB (AWS RDS)
Running n8n with the execution process [own(default), main]:
Running n8n via [Docker, npm, n8n.cloud, desktop app]: AWS ECS
Thank you for looking at my question. I am not sure how to post another example with mock data… Is there a node I can use for custom data?
Either way, it shouldn’t really matter what comes out of the mysql node. In this case we had 24 items, and only one was returned by the mysql query. I am trying to append an error to anything that was not returned by the query. In other words, I am just trying to check whether or not the received data exists in the mysql table.
UPDATE: I tried updating the cluster from v0.213.0 to 0.216.0 in case it’s a bug, but the error persists.
Thank you!
Hi @wumbowarrior, not everyone has a ready-to-run MySQL instance. But even if that would be the case we don’t have access to your data and wouldn’t know what exactly your query returns.
So it’d be great if you could provide more details allowing us to reproduce your specific problem. Also, narrow down the problem as much as possible. For example:
Does the problem also occur without the Execute Workflow Trigger and Compare Datasets nodes? If not, throw out the nodes that aren’t part of the problem.
Remove all lines in the Code except the ones actually required to reproduce the error
Running a random query on a random MySQL instance, then attaching a code node running return $input.all(); is working fine for me. So this is not a general error and I very much suspect it is related to your specific setup instead.
Sure enough, if I replicate a situation like your workflow, I don’t have any errors. I don’t understand how the issue would be with the data, as the structure is still the same.
Actually, the only thing I can see that is different is that the data is coming from a previous workflow. I am using code nodes in the previous workflow, and as soon as it enters the new workflow this happens… Is it possible this is a bug?
I’ve just hit the same issue (Running 0.219.1) , and this is in my subworkflow, but if I swap the ‘code node’ out for a ‘Set’ node the execution is OK.
I’m not sure about 0101binary0101’s issue, but mine was resolved after an update. I think it was a bug with referencing data from within a workflow that has been executed by another workflow.
I’ll try and isolate the conditions of the this sub-workflow failure as it’s part of a much bigger workflow, but it says it’s passing 1 item, to the code node and then bam, fails, all it’d be doing is returning the response of a block before the IF , I tend to put ‘code’ nodes in places like this so that I can use the data for re-testing.
I have a workflow that hit this problem. But other work fine. After comparing the queries, I found out the one that works fine has specified the fields to select, but the one that fails select * which include two timestamps - they are the reasons.
Somehow under the hood, n8n engine probably processes the return data by .json or other way, before passing them to output as $input or $items. That failed as timestamp is not compatible with n8n after some upgrades.
