Describe the issue/error/question
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
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
Returning that should still work totally fine. Is even the default for all Code-Nodes.
Can you please post an example that we can simply see the error by executing the workflow (so mock data of MySQL Node). Thanks!
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.
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.
My minimal test workflow:
To allow folks without MySQL to run the workflow I could replace the MySQL node (for example) with a Set node:
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.
Code Node Run:
Set Node Run:
I am not able to reproduce this, As a test I have used the workflow below. Can you give it a run and see if you still get the issue?
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.
Yeah it seems crazy I know.
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.
What did the small test workflow do?
Yeah that’s working … that’s why it’s a bit crazy
Even putting that ‘Code’ setup node into the parent workflow and passing it to the subflow is ok.
Sounds like the issue is going to be something funky in the flow. Once you have an example that can be reproduced let me know
I probably found the cause for this bug.
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.
Method Date.prototype.toISOString called on incompatible receiver [object Date] - Questions - n8n
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.