Backend IMAP calls block the event loop and have no timeout #5

New Issue

2026-06-17T17:12:30+01:00

lyrathorpe commented

2026-06-17 17:12:30 +01:00

handle_stat (proxy_server.py:233) and handle_list (proxy_server.py:244) call IMAPBackend.fetch_message_size synchronously inside a loop, on the asyncio event loop thread. Every blocking imaplib round-trip stalls all other clients. There is also no socket timeout on imaplib (smtplib already uses timeout=30), so a dead backend hangs the session indefinitely.

Fix:

Either fetch all sizes in a single round-trip (UID FETCH 1:* (RFC822.SIZE)) or wrap the blocking calls in asyncio.to_thread.
Apply a connection/socket timeout to the IMAP client.

Acceptance:

STAT/LIST do not block the event loop.
An unresponsive IMAP backend fails within a bounded time rather than hanging.

handle_stat (proxy_server.py:233) and handle_list (proxy_server.py:244) call IMAPBackend.fetch_message_size synchronously inside a loop, on the asyncio event loop thread. Every blocking imaplib round-trip stalls all other clients. There is also no socket timeout on imaplib (smtplib already uses timeout=30), so a dead backend hangs the session indefinitely. Fix: - Either fetch all sizes in a single round-trip (UID FETCH 1:* (RFC822.SIZE)) or wrap the blocking calls in asyncio.to_thread. - Apply a connection/socket timeout to the IMAP client. Acceptance: - STAT/LIST do not block the event loop. - An unresponsive IMAP backend fails within a bounded time rather than hanging.

lyrathorpe added the enhancement label 2026-06-17 17:12:30 +01:00

lyrathorpe referenced this issue from a commit

2026-06-17 17:22:30 +01:00

fix: correct POP3 RETR/TOP, static maildrop, and IMAP fetching

lyrathorpe referenced a pull request that will close this issue

2026-06-17 17:22:53 +01:00

Fix POP3/SMTP correctness and IMAP robustness #10

lyrathorpe closed this issue

2026-06-17 17:33:11 +01:00

lyrathorpe referenced this issue from a commit

2026-06-17 17:33:12 +01:00

Fix POP3/SMTP correctness and IMAP robustness (#10)