Bug Description

The Email Trigger (IMAP) node can silently lose its connection without producing any log output, without triggering a reconnection attempt, and without invoking the configured Error Handler workflow. The workflow continues to show as "Published" (active) in the UI, but the IMAP trigger is effectively dead. Incoming emails remain unprocessed indefinitely. The user has no way to detect this condition other than manually noticing unread emails.

Additional context

This was observed after a Hetzner Cloud Firewall rule change that temporarily interrupted connectivity on port 993. Under normal circumstances, IMAP disconnects are logged and trigger reconnection attempts. In this case, the connection was lost during or after the firewall change, and the trigger node entered a state where it believed it was still connected but had no active TCP socket. The forceReconnect option (set to 55 minutes) did not recover the connection either, suggesting the internal reconnect timer may also have died silently. Related: #29996 (Options-only changes not restarting triggers on Publish)

To Reproduce

The exact trigger for the silent failure is not yet identified, but the following sequence was observed:

1. Workflow "Parse DMARC reports…" is active with an Email Trigger (IMAP) node (typeVersion 2) and forceReconnect: 55 configured
2. The IMAP trigger is connected and processing emails normally
3. An external event disrupts the IMAP connection (in this case: a Hetzner Cloud Firewall rule for port 993 was temporarily removed and re-added)
4. The IMAP trigger loses its connection
5. No Email Read Imap: Connected closed unexpectedly log message is produced
6. No reconnection attempt is logged
7. No Error Handler workflow is triggered
8. The workflow continues to show "Published" in the UI
9. ss -tn | grep 993 inside the container confirms: no active TCP connection to the IMAP server
10. Emails accumulate unread in the mailbox
11. Only a full container restart (docker restart) re-establishes the IMAP connection

Expected behavior

When an IMAP connection is lost, the trigger node should:

1. Log the disconnection event (as it normally does with "Connected closed unexpectedly")
2. Attempt to reconnect (with exponential backoff, as it normally does)
3. If reconnection fails permanently, invoke the configured Error Handler workflow
4. The workflow status in the UI should reflect the actual state of the trigger

A silently dead trigger with no logging, no reconnection, and no error notification is the worst possible failure mode — the user has no indication that mail processing has stopped.

Debug Info

Debug info

core

• n8nVersion: 2.20.7
• platform: docker (self-hosted)
• nodeJsVersion: 24.14.1
• nodeEnv: production
• database: sqlite
• executionMode: regular
• concurrency: -1
• license: enterprise (production)
• consumerId: fb4613cc-eb98-48aa-bfc4-d1649f71047d

storage

• success: all
• error: all
• progress: false
• manual: true
• binaryMode: filesystem

Generated at: 2026-05-21T08:23:39.834Z

Operating System

Ubuntu 24.04

n8n Version

2.20.7

Node.js Version

24.14.1

Database

SQLite (default)

Execution mode

main (default)

Hosting

self hosted