Hey!
What kind of mistake is this? How to find out the reason?
If you hover over it, it should display a tooltip with the following message “The workflow execution is probably still running but it may have crashed and n8n cannot safely tell.”.
Jan, thanks for the answer!
On my VPS server, load the central processor, the consumption of RAM and disk calls are all extreme. Could it be related to this?
How can you avoid this? Delayed time for node execution?
How do you run n8n? With or without queue? Do the workflows run in the main process or an own one?
Is it difficult for me to answer these questions? You mean the server part or part of the n8n software?
What environment variables do you have set and to which values (excluding user and password)?
Yes exactly. In this case, you are running all workflows in a separate process without a queue.
So does honestly not sound to me like it should display you the status “unknown” in this case for the workflow you posted. I will inform the developer which worked on it to have a look on Tuesday (public holiday here on Monday) to see if something is wrong and if so fix it.
So unless you need any functionality from the latest versions you can temporarily roll back to 0.107.0.
1 Like
Thanks, try it.
I rolled back to 0.107.0 and added a 1 sec wait in front of the last google sheets node. Everything works stably.
That is great to hear! But wonder about that 1 sec wait. Without it, it is not stable? What does then happen exactly?
Google sheets stops responding after about 50 requests.
Hi @Roket
This is related with the read limit rate when getting data from Google sheets.
If you are doing a lot of requests, probably you have to evaluate to read your data source outside of Google or apply some time waits in your logic between reads/writes.
3 Likes
Ah OK, yes that makes sense then. It is planned to improve that in the future to be able to define rate-limits for all nodes that make HTTP Requests. Sadly do I not have an ETA yet.
2 Likes
Hey @Roket
I am investigating this issue and managed to replicate this problem when configuring n8n to save execution progress, via this setting.
Did you turn this feature on?
Hey krynble!
Status “unknown” appeared before clicking this checkbox. But, then I made attempts to rectify the situation, including clicking this checkbox. Further, the problem with the status was repeated.
@jan @krynble We are using n8n in queue mode, and we haven’t turn the Save Execution Progress feature, still we are getting this issue
Hey @aashish.jain You might get Unknown execution status if n8n is unable to reliably tell whether an execution has finished or failed.
Most probably, the execution failed and the Unknown status is there because a worker might have crashed during the execution, for instance. When that happens, you might end up with executions in Unknown status.
@krynble When we executed 10k workflows simultaneously, we have seen that many workflows got unknown status, So we are assuming that our worker got crashed. We have a 3 worker setup still we got this issue, So how we can avoid such kind of issues.
By default does each worker run up to 10 executions in parallel. If that causes crashes, then you would either have to increase the memory of your workers or decrease the number of parallel executions. That can be done by adding the flag --concurrency-5 which will then ensure that each worker only runs 5 executions at any given time.
1 Like