Error Detail Missing in Execution View about n8n HOT 6 OPEN

Hey @dkindlund,

Looking at the workflow I would say the error occurred on the Airtable node but more information would be needed.

Looking at the output you collected from the error trigger that may also have been in the n8n log it would suggest the issue occurred because of a memory issue this means the node never really got a chance to start.

You are not wrong we really should put this information in the UI somewhere but as it is a workflow level error it wouldn't be right to put it under the node output so we would need to think about how to best display it.

I suspect when the workflow process runs out of memory though it doesn't have the memory to add that to the node which is why it isn't there. We should probably make it clearer as well that the settings are for the workflow itself and not the system in general.

This isn't really a bug but I will keep this open and get a dev ticket created on Monday to look into how we can improve this.

from n8n.

Thanks for the analysis, @Joffcom -- I agree it's a hard problem. Just trying to offer a user's perspective about it for now. Thanks!

from n8n.

One other point: When I checked Google Cloud Run's memory usage in the single container around the time when this out-of-memory error was reported, I see that only ~15% of the container's memory was actually allocated:

Then, when I checked the logs, I see this sort of activity:

So the timeline of events appear to be:

• The container crashed earlier (not sure why it got restarted by Google Cloud Run)
• Upon recovery, the new container attempted to recover a the crashed job:
  Attempting to recover execution 3346
• During the recovery of this job, it somehow ran out-of-memory

We're left with a bunch of questions/insights, such as:

1. Why did the container crash to begin with? Looking through the older logs, there were no entries that provide any clues as to why the container crashed.

2. When attempting to recover a crashed workflow, that recovery logic appears to trigger out-of-memory issues even though the container had more than enough memory allocated at the time. (I suspect there might be some sort of out-of-memory bug in n8n's workflow recovery logic that can be hard to pinpoint.)

from n8n.

A couple of other data points about this n8n deployment:

• It's a single container deployed in Google Cloud Run
• Running [email protected]
• Allocated 4 vCPUs and 2GB RAM
• EXECUTIONS_MODE=regular
• NODE_OPTIONS=--max-old-space-size=1536
  (Based on documented recommendations found here.)

from n8n.

Oh, this might be a factor:

So essentially, Google Cloud Run can kill/restart the container at any time to run it at a cheaper rate -- so not necessarily because of any sort of n8n error.

I guess the main issue is: n8n's workflow recovery logic doesn't quite work correctly upon container restart -- hence the spurious out of memory errors we're seeing.

from n8n.

Ah yeah cpu will cause a similar message, we don’t have container restart logic to restart workflows though that is something that needs to be manually done.

from n8n.