How do you debug forever executing workflows with no progress?

[RedDot]

Frequently when making a workflow I encounter the same issue. I click execute, but nothing happens, the little spinner goes round and round, but that’s it.
When it’s working, I would expect to see some green ticks as it progresses.
What am I supposed to do about this? It’s still like below 15 minutes later. I’ve had this going for hours before like this.

Sometimes I restart the docker container and that fixes it, sometimes I just leave it and come back to it later and it works. It has been working fine for a few weeks now, but today it seems to have fallen over again.

Here’s a screen recording showing an example:

I’ll share the workflow as requested, but that’s not really the point. This seems to happen randomly and for all workflows.

Share the output returned by the last node

Information on your n8n setup

• n8n version: 0.227.1
• Database (default: SQLite): Postgres
• n8n EXECUTIONS_PROCESS setting (default: own, main): default
• Running n8n via (Docker, npm, n8n cloud, desktop app): docker
• Operating system: Linux hassio 5.10.103-v7l+

I have limited executions logs:
- EXECUTIONS_DATA_PRUNE=true
- EXECUTIONS_DATA_MAX_AGE=168 # hours
- EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000

Nothing that interesting running docker stats

UPDATE 1:
Interesting docker logs:

Editor is now accessible via:
http://localhost:5678/
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
Attempt to read execution was blocked due to insufficient permissions
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
Attempt to read execution was blocked due to insufficient permissions
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
Attempt to read execution was blocked due to insufficient permissions
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
Attempt to read execution was blocked due to insufficient permissions
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.
The session "zetllvq9ab" is not registered.

UPDATE 2:
I’ve accessed it locally instead of through my HAProxy/Cloudflare proxy and it seems to be working now. Is there some specific settings n8n requires to be used through a reverse proxy? My frontend handles all the SSL etc, so I prefer to use it that way. This might explain the issue I have had where I have to force refresh the browser to get a login page for n8n…

[Jon]

Hey @RedDot,

I have seen this a few times and it does tend to be a proxy issue like you have found but the way to fix it would depend on the proxy you are using. You could try setting N8N_PUSH_BACKEND to websocket and seeing if that helps.

[RedDot]

Thanks @Jon that seems to have fixed it. Although it has been intermittent and I had to restart it… so it will take some time to be sure.

Before you responded I saw in the installation docs for Caddy it says to use the option flush_interval -1.

flush_interval is a duration value that adjusts how often Caddy should flush the response buffer to the client. By default, no periodic flushing is done. A negative value (typically -1) suggests “low-latency mode” which disables response buffering completely and flushes immediately after each write to the client, and does not cancel the request to the backend even if the client disconnects early.

I’m not sure what the HAProxy equivalent of that is. tune.sndbuf.client?
As your solution seems to have worked, I will not touch HAProxy for now.

UPDATE:
I’ve added an option to Haproxy n8n backend:

option http-no-delay

I think this is the equivalent in Haproxy for Caddy flush_interval -1.