I’m not entirely sure if this is a bug or intended design… Can anybody shed some light on this?
Describe the problem/error/question
When creating a workflow that has a form trigger and and ending form, the ending form ‘stalls’ if the workflow takes too long. The attached workflow includes a 1 sec wait. When you test the workflow by entering some text and then hitting submit, the form never ‘completes’. If you go back to the workflow and disable the wait node and test the same thing, the form completes no problem.
What is the error message (if any)?
No error messages.
Please share your workflow
Share the output returned by the last node
The last node doesn’t output anything. It shows a ‘waiting’ indicator when i test/execute the workflow.
The wait is basically a simulation of the problem. Since i found this issue when creating a bigger automation that requires some processing time (async api stuff).
Can you share some of your information about how you run your n8n? Since im selfhosted im wondering if theres something wrong perhaps on that end.
I’ve tested it on the cloud instance. Tomorrow I can check the self-hosting.
With the wait node there is one thing - if the waiting time is more than 90 secs, the execution will be offloaded to the database (like sleep). So I suppose the form connection will die after 1 minute (usually, it’s the default timeout for any connection)
The operations i’m talking about take barely a second. Which is why the wait is also set to a second. Typical AI agent integrations take even longer (which is another usecase I’m considering in the future) so operations that take a few seconds (let’s say 5 seconds) would be expected to work.
since you claim it’s running fine on the cloud instance, I’ll check for settings and updates but from what I saw int the latest release notes, I should be up to date with the correct settings. So i’m not sure if there’s anything I can change.
Hm… I have the same issue on my self-hosted instance. As I see in the dev console, the first request goes to the form-test endpoint, then it gets redirected to the form-waiting endpoint, but as we have a waiting node in-between, the waiting endpoint is not listening yet. It will start listening only when the form node will be executing. And when the form node start to be executing, our pending request should be completed. But seems my reverse proxy doesn’t do that and the pending request hangs. On the cloud instance there is no issues with that as the proxy correctly handle that request.
Hanged request on self-hosted instance (wait node is set for 10 secs)
Correct request on the cloud instance (wait node is set for 10 secs)
That’s some serious deep-dive info you got there. Thanks for looking this deeply into it. Glad to hear it’s not expected behavior but that means it does seem like a bug I guess. Should we create an issue on github?
Is there any feedback from anyone so far? I feel like there might be other issues related to timing. I just ran a worfklow that involved a loop of 93 items that ended up taking almost 1 hour of time. The workflow ui stopped responding when the actual tasks actually completed. It looked like the loop was running the items but the promise of the loop was never completed. Might be a long shot that this is related but its just another issue where async things seem to be influencing other behavior
the only thing i’ve got going over here is a reverse proxy to map my localmachine:4567 to my.public-site.com. Not sure how that could impact that. Do you have any guiding as to how i can test this?
