I’m facing an issue where a workflow with an Email Trigger (IMAP) node deactivates itself immediately when I try to turn it on, throwing a WorkflowActivationError which is caught by the workflow’s Error Trigger.
However, manual execution works perfectly fine without any errors.
Error details (caught by Error Trigger):
[
{
"trigger": {
"error": {
"message": "There was a problem with the trigger node \"Email Trigger (IMAP)\", for that reason did the workflow had to be deactivated",
"timestamp": 1785767782822,
"name": "WorkflowActivationError",
"context": {}
},
"mode": "trigger"
},
"workflow": {
"id": "zTAdqKiYBPODh3yr",
"name": "03.03. Яндекс -> amoCRM (deleted@pioneercert.ru)"
}
}
]
Hi @Sokol
WorkflowActivationError is the wrapper n8n hands to the Error Trigger when a trigger node fails, and trigger-node errors always arrive with context: {} and no cause, so the real IMAP failure never reaches the UI and goes to the instance log instead. Manual runs do a single fetch and close, activation holds the connection open, which is why only activation trips. Turn the workflow on and read the log right after:
The line beginning “Email Read Imap:” carries the actual reason, usually a connection closed unexpectedly, an auth rejection from the server, or a mailbox error, and that decides the fix. On Cloud those logs aren’t reachable from your side, help@n8n.io can pull them for workflow zTAdqKiYBPODh3yr.
The missing detail in the error payload is tracked here:
We have taken a look at this and it looks like it might be fixed in a recent release, Please update and see if you are still running into the same problem.
Hi,
Still on 2.33.3, same ECONNRESET/EPIPE pattern as before upgrade, no change.
One thing I noticed, it is not isolated to one mailbox, mail@, deleted@, and notification@ on the same VPS are all dropping at the same time, in the same tight loop system. That had me wondering if this is really a network layer thing, and not something Yandex or n8n is doing per account. Like the VPS firewall or conntrack table killing idle connections before n8n has a chance to reconnect.
I haven’t checked the conntrack timeout yet, will run
sysctl net.netfilter.nf-conntrack-tcp-timeout-established and post the value. I’m also going to see what Force Reconnect is currently set on these nodes as I’m not sure it is even configured.
Why does the 15-minute setting not match what I saw in the log?
I appreciate you sharing it. One item stands out: although Force Reconnect is set to 15 minutes, the ECONNRESET/EPIPE problems were occurring back-to-back in a tight loop rather than roughly every 15 minutes, according to the log you previously gave. You would anticipate failures scattered about 15 minutes apart rather than a sudden spike if Force Reconnect were the driver. Therefore, this option is most likely not the primary reason; the connection is being terminated much before the allotted 15 minutes have passed.
It’s worth verifying if the values of the other mailboxes (mail@, notification@) are the same or if one is set differently or unset. That would make it easier to determine whether it’s per-node configuration or something that affects them all equally.
Still planning to check the conntrack timeout, will post that value once I have it that’s the piece that’ll actually tell us if this is the VPS/firewall or something in n8n’s reconnect handling.
If you need any additional data or if I sent the wrong thing, please let me know. I will send the additional information so that we can find a solution.
run docker logs n8n-n8n-worker-1 2>&1 | grep -i imap and see what comes back. Provide me the results.
Also what EXECUTIONS_MODE is set to (or whether you are using N8N_DISABLE_PRODUCTION_MAIN_PROCESS).
Also provide the worker log output from around the same time window as one of the failures in your docker ps/log screenshot, so the timestamps can actually be lined up against the main-process failures.
whether that LOGIN error shows up repeatedly across the different mailboxes, and whether the timestamps cluster close together because if multiple mailboxes on the same domain/IP are all retrying LOGIN around the same moments, that looks like Yandex’s anti-abuse/rate-limiting kicking in from repeated login attempts hitting them from one VPS IP, not a per-account issue.
My suggestion:
that sc= code is a Yandex-side trace/support identifier, worth you taking it directly to Yandex support, since if this is rate-limiting, it’s not something fixable purely from the n8n config side.
@Sokol the call that fails is LOGIN, not the socket. “LOGIN internal server error sc=…_imap-production-main-623” is Yandex refusing the session, and the ECONNRESET and EPIPE pairs are those sessions being dropped right after. No n8n setting changes that, the fix is on the mailbox side.
For each of deleted@, mail@ and notification@:
Log into that mailbox once at mail.yandex.com. The User Agreement is accepted on first web login, per mailbox, and service mailboxes usually never have been.
In Settings > Email clients, confirm “From the imap.yandex.com server via IMAP” is on and the authorization method is set to app passwords.
Generate an app password for that mailbox in Yandex ID and use it in the n8n IMAP credential instead of the account password.
Yandex also blocks mailboxes its security system flags as suspicious, usually ones with no real name or linked phone, and that block clears on its own after a couple of hours, which fits errors that come and go while manual runs still work. Troubleshooting email client issues | Yandex Mail
