I am working in a cloud instance and for the past week Javascript code node execution has been super slow (7+ seconds on a 120lines data handling script that used to run in milliseconds). This behaviour makes n8n unusable for opening slack modals that have a 3s timeout. I would like to know if any chnage was made to such instances and if any kind of fix is possible to make the workflow still usable.
What is the error message (if any)?
there is no apparent error other than this massive slowdown mentioned before
Please share your workflow
Share the output returned by the last node
the ourput is correct just the execution times are abnormally high
Hi @Davide_Peron
Every Code node execution is dispatched to a task runner over the broker, so the node’s wall time is the dispatch wait plus the script, not the script alone. A 120 line reshape is microseconds of actual work, so the 7 seconds is the wait for a runner. Drop a throwaway Code node containing return items next to it and time that, it will sit at roughly the same number.
Nothing in “STEP 1 EDIT” needs a runtime, it only reads blocks and builds one JSON object. Rebuild it in an Edit Fields (Set) node with Mode set to JSON Output and paste the modal body into the JSON Output field, using expressions for the draft text and CC lookups. Set runs in the main process with no runner hop, which puts views.open back inside Slack’s 3 second trigger_id window.
Whether something changed on your instance a week ago is only answerable on n8n’s side, so send the instance URL and a couple of the slow execution IDs to help@n8n.io.
Thanks to both for your replies.
I will ask my manager to update the instance and will also email the IDs to check what is going on, since this is at the instance level, not just in this workflow.
I am now in contact with N8N support and they also mentioned the use of Edit blocks instead so i gave it a try.
Although it is slightly faster than using code nodes, each node takes around 10ms to execute, but the wall clock time is still borderline unusable for Slack’s 3s timeouts.
All the nodes executed in the specific execution have a cumulative time of 227ms while the full execution time was 2.652s and no code node was used whatsoever, and no other workflows executions were firing at the same time.
This issue is something that we never had before and that happened from around Agust 14th before that evrything was working flawlessly even with code nodes and since 2 weeks prior to the first incident appearing no modifications were made to any of the workflows in our instance
Thanks, @Lopez, for your reply. I can confirm that Save execution progress is turned off.
Then, as I imagined, it is more of a platform/instance change rather than a workflow-related issue.
I hope support will be able to give me some more insight and figure out what the problem really is.
I will update the thread in the future if a solution is found to the issue
With the help of the support, we were able to solve the problem.
There were some old workflows that were stuck between published and unpublished due to a recent update that rendered some nodes obsolete.
These workflows still received data, and the system tried to rerun them in an infinite loop since they failed, but it was not an execution error this casueda growing strain on the CPU making the platform unusable.
Once the workflows were manually unpublished, everything went back to normal