My workflow is using an IMAP Trigger node to fire an event whenever a mail is received in the mailbox. However, I discovered that after activating the workflow, the trigger will stop working after running a period of time (half to an hour approx.). There will be no more events fire up even though the mailbox has new mails. Also, when the trigger stopped working, I can no longer save the workflow or activate/deactivate the workflow, it will just hang in there unless I refresh my browser. My temporary solution for this problem is to restart the container after hitting the problem, but the problem always come back.
What is the error message (if any)?
There are no error messages. However, I discovered that whenever this problem occurs and I try to save the workflow, there is a request made to the n8n server that never get response. I guess this could be the reason why it stucks when I try to click save or toggle active/inactive of the workflow.
Can you give a little bit more detail on your docker setup, especially in relation to connections? The fact that this works after restarting the container has me curious
Hi @EmeraldHerald Thanks for the quick reply.
There is no special configuration on the container connections. Do you know if the hanging request is what causing this issue?
I just did a packet capture on both my workstation browser and the n8n container while I try to toggle “active/inactive” button of the workflow to test out the hanging request. The server did receive the request from my workstation, it just didn’t reply with anything.
Hi @EmeraldHerald, I have the same issue. I have tried versions v1.44.1 and v1.45.0. The IMAP trigger loses connection after running for a while, and the workflow cannot be deactivated, showing the following error:
Workflow could not be deactivated:
Request failed with status code 504
In the n8nEventLog.log, I did not find any related errors. If you need me to provide any information, please let me know.
Hi, @hugo222, after some simple guessing and debugging, I suspect that this issue is caused by fluctuations in our network. The IMAP trigger requires a persistent connection to the mail service. My network goes through a Clash proxy, and if the proxy node is switched after the IMAP trigger workflow starts, this issue occurs. I was able to manually reproduce the problem.
Hi @EmeraldHerald . Thank you for your quick reply! I am happy to help with n8n. I set “Force Reconnect Every Minutes” to five minutes and then ran the workflow. After running the workflow, I manually switched the network, which caused an IMAP connection error. Additionally, after five minutes, it appears the workflow didn’t continue to run and seemed to have been shut down .
Here is the log content:
n8n-1 | 2024-06-06T13:53:42.913Z | debug | Adding triggers and pollers for workflow "Mail feed" (ID: 8hFS5NoKiTt7Tt1l) "{ file: 'ActiveWorkflowManager.js', function: 'addTriggersAndPollers' }"
n8n-1 | 2024-06-06T13:53:42.915Z | debug | Loaded static data for node "EmailReadImap" "{\n staticData: { lastMessageUid: 41 },\n file: 'LoggerProxy.js',\n function: 'exports.debug'\n}"
n8n-1 | 2024-06-06T13:53:44.266Z | debug | Email Read Imap: Shutting down workflow - connected closed "{ file: 'LoggerProxy.js', function: 'exports.debug' }"
n8n-1 | 2024-06-06T13:53:47.980Z | debug | Querying for new messages on node "EmailReadImap" "{\n searchCriteria: [ 'UNSEEN', [ 'UID', '41:*' ] ],\n file: 'LoggerProxy.js',\n function: 'exports.debug'\n}"
n8n-1 | 2024-06-06T13:53:47.981Z | verbose | Workflow "Mail feed" (ID: 8hFS5NoKiTt7Tt1l) activated "{\n workflowId: '8hFS5NoKiTt7Tt1l',\n workflowName: 'Mail feed',\n file: 'ActiveWorkflowManager.js',\n function: 'addTriggersAndPollers'\n}"
n8n-1 | 2024-06-06T13:53:51.189Z | verbose | IMAP connection experienced an error: (EPIPE) "{\n error: Error: This socket has been ended by the other party\n at genericNodeError (node:internal/errors:984:15)\n at wrappedFn (node:internal/errors:538:14)\n at Socket.writeAfterFIN [as write] (node:net:561:14)\n at JSStreamSocket.doWrite (node:internal/js_stream_socket:199:19)\n at JSStream.onwrite (node:internal/js_stream_socket:35:57)\n at TLSSocket.Socket._final (node:net:532:28)\n at prefinish (node:internal/streams/writable:907:14)\n at finishMaybe (node:internal/streams/writable:921:5)\n at TLSSocket.Writable.end (node:internal/streams/writable:836:5)\n at TLSSocket.Socket.end (node:net:723:31)\n at endWritableNT (node:internal/streams/readable:1722:12)\n at processTicksAndRejections (node:internal/process/task_queues:81:21) {\n code: 'EPIPE',\n source: 'socket'\n },\n file: 'LoggerProxy.js',\n function: 'exports.verbose'\n}"
n8n-1 | 2024-06-06T13:53:51.190Z | debug | Email Read Imap: Shutting down workflow - connected closed "{ file: 'LoggerProxy.js', function: 'exports.debug' }"
n8n-1 | 2024-06-06T13:53:52.913Z [Rudder] debug: in flush
n8n-1 | 2024-06-06T13:53:52.913Z [Rudder] debug: cancelling existing flushTimer...
n8n-1 | 2024-06-06T13:53:52.965Z | debug | Wait tracker querying database for waiting executions "{ file: 'WaitTracker.js', function: 'getWaitingExecutions' }"
n8n-1 | 2024-06-06T13:54:52.966Z | debug | Wait tracker querying database for waiting executions "{ file: 'WaitTracker.js', function: 'getWaitingExecutions' }"
n8n-1 | 2024-06-06T13:55:52.966Z | debug | Wait tracker querying database for waiting executions "{ file: 'WaitTracker.js', function: 'getWaitingExecutions' }"
n8n-1 | 2024-06-06T13:56:52.967Z | debug | Wait tracker querying database for waiting executions "{ file: 'WaitTracker.js', function: 'getWaitingExecutions' }"
n8n-1 | 2024-06-06T13:57:52.967Z | debug | Wait tracker querying database for waiting executions "{ file: 'WaitTracker.js', function: 'getWaitingExecutions' }"
n8n-1 | 2024-06-06T13:58:52.967Z | debug | Wait tracker querying database for waiting executions "{ file: 'WaitTracker.js', function: 'getWaitingExecutions' }"
n8n-1 | 2024-06-06T13:59:52.967Z | debug | Wait tracker querying database for waiting executions "{ file: 'WaitTracker.js', function: 'getWaitingExecutions' }"
Hmm Can you share any further details on your proxy setup / any relevant Docker settings? I’m not surprised to see the connection closed details there, but I am surprised it won’t reconnect.
@Lz1y Thanks for the suggestion. My current IMAP host configuration uses BIG-IP, so its likely the reason of “fluctuations” causing the IMAP connection to die. I have updated my host configuration to point towards one of the exchange servers instead, hopefully it can solve the issue temporarily, will keep you posted on this.
Also, force reconnect option on IMAP Trigger Node doesn’t work for me as well. @EmeraldHerald I find it strange that the IMAP connection error caused us unable to save or activate/deactivate the workflow, were you able to reproduce the problem?
Maybe you can try to reproduce this issue by closing the TCP connection with the mail service provider, using something like tcpkill .
I personally suspect that the problem occurs when there is an IMAP connection error, and the closeFunction is called. In this function, the reconnectionInterval is cleared.
Thanks for posting this!