UI fails to response during manual execution

Questions
1

My n8n is now having some issues. When I manually start a workflow, the UI shows nothing except the button turns to “Executing Workflow” and it keeps showing this forever. However, when I open the executions on the sidebar, I saw my manual workflow already completed and I could check its results as normal too.

I wonder if something got ‘jammed’ underneath the hood. Before this condition happened, I was manually running a workflow but it got a spin at a node for a long time, so I clicked the stop button, but I then closed the website before it was completed or threw an error after waiting for a long time.

Not sure if that’s what making this to happen, but if so, how can I work around it? I’ve already do docker-compose down and up for a few times. Thank you for you help.

2

Hi @Jiu_Kam, I am so sorry for the trouble. When first reading this I thought it might be related to this post which appears to be related to the logic introduced with user management.

However, it seems this is not quite the same. I could, however, not reproduce the behaviour based on your description alone. Are you perhaps using a reverse proxy server not proxying communication between your n8n server and the browser here?

Are you also having this problem when running n8n locally?

3

Thank you for your reply, Jam!

Due to unknown reasons, the UI is normal again after a few hours. Well, I’m not quite sure what just happened, but I will just let it be unless this problems happen again. Thank you again.

1 Like
4

Hello!

I seem to be seeing a similar issue: Manual workflow executions from the UI do not seem to get execution feedbacks from the servers. The execution completes successfully (I can see it in the history) but the UI seems to hang in the “Executing Workflow” status, with the spinner and the stop button.

When pressing the Stop button, I do get the execution results in the UI (and the notification that the workflow couldn’t be stopped because it already completed).

Nothing seems fishy network-wise, all traffic seems to complete happily.

Nothing fishy in the debug logs:

2022-04-21T07:52:12.045Z | debug    | Running node "Slack" started {"node":"Slack","workflowId":"7","file":"WorkflowExecute.js"}
2022-04-21T07:52:12.045Z | debug    | Send data of type "nodeExecuteBefore" to editor-UI {"dataType":"nodeExecuteBefore","sessionId":"icv5ojsyqv","file":"Push.js","function":"send"}
2022-04-21T07:52:12.061Z | debug    | Proxying request to axios {"file":"NodeExecuteFunctions.js","function":"proxyRequestToAxios"}
2022-04-21T07:52:12.292Z | debug    | Running node "Slack" finished successfully {"node":"Slack","workflowId":"7","file":"WorkflowExecute.js"}
2022-04-21T07:52:12.293Z | debug    | Save execution progress to database for execution ID 32  {"executionId":"32","nodeName":"Slack","file":"WorkflowExecuteAdditionalData.js","function":"nodeExecuteAfter"}
2022-04-21T07:52:12.293Z | debug    | Received child process message of type processHook for execution ID 32. {"executionId":"32","file":"WorkflowRunner.js"}
2022-04-21T07:52:12.293Z | debug    | Executing hook on node "Slack" (hookFunctionsPush) {"executionId":"32","sessionId":"icv5ojsyqv","workflowId":"7","file":"WorkflowExecuteAdditionalData.js","function":"nodeExecuteAfter"}
2022-04-21T07:52:12.294Z | debug    | Send data of type "nodeExecuteAfter" to editor-UI {"dataType":"nodeExecuteAfter","sessionId":"icv5ojsyqv","file":"Push.js","function":"send"}
2022-04-21T07:52:12.302Z | verbose  | Workflow execution finished successfully {"workflowId":"7","file":"WorkflowExecute.js","function":"processSuccessExecution"}

image
image941×615 82.4 KB

image
image807×391 73.3 KB

image
image1444×692 102 KB

I suspect a reverse-proxy-related issue concerning the polling process… Can you advise an expected nginx configuration to support the polling?

The calls to /rest/push?sessionId=xxx are running very long, but I suppose that’s the normal polling design (?) - they used to time out after 60s because of my nginx proxy timeout, so I bumped this up to 1h - I sitll however sometimes get a ‘Connection Lost’ message, but this does not seem to be related to the issue with execution data.

My nginx reverse proxy is the default kubernetes nginx ingress controller, with only these 2 configuration annotations:

    nginx.ingress.kubernetes.io/proxy-read-timeout: '3600'
    nginx.ingress.kubernetes.io/proxy-send-timeout: '3600'

Final notes:

  • I have another very similar setup that seems to work fine (although on an older n8n version). The main configuration difference is that the new, failing setup has queue processing enabled.
  • Latest 0.173.1

Many thanks!

1 Like
5

OK, I’ve managed to sort this out (or at least work around it)…

Turns out there was another proxy in the path (https://gogatekeeper.github.io/ - used just for authentication, which we’ve plugged into our own Keycloak identity server). It’s not exactly clear what issues it was causing, and I couldn’t get it to work, but routing all the /rest/* endpoints to bypass this proxy has solved the issue (which I guess is secure enough now that user management is enabled and has a UI authentication flow). Now we only have our kubernetes ingress controler as proxy, and with the appropriate timeouts it worked out fine.

2 Likes