Skip to content

fix: retry transient IMAP aborts - #24

Open
giscebot wants to merge 1 commit into
mainfrom
fix/imap-abort-retry
Open

fix: retry transient IMAP aborts#24
giscebot wants to merge 1 commit into
mainfrom
fix/imap-abort-retry

Conversation

@giscebot

Copy link
Copy Markdown
Collaborator

Summary

  • reconnect once when an IMAP command aborts because the server closed the socket
  • retry the complete reader pass using the durable UID cursor
  • preserve the failure signal when the retry also aborts

Why

Gmail can transiently close an IMAP connection during SELECT. The reader
currently exits immediately, delaying notification ingestion until the next
timer run and reporting an avoidable Sentry error.

The retry is bounded to one reconnect. Replaying the pass is safe because
last_uid advances after each handled message and message_id is unique in
the durable queue.

Tests

  • PYTHONPATH=src /home/openclaw/.pyenv/versions/erp3/bin/pytest -q tests/test_reader.py tests/test_reader_run.py — 9 passed
  • PYTHONPATH=src /home/openclaw/.pyenv/versions/erp3/bin/pytest -q — 160 passed

Closes #23

Requested by: automated Sentry alert in #23 (no human requester)

@ecarreras

Copy link
Copy Markdown
Member

@giscebot open this pull-request against the main repo if this is a fork

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

IMAP4.abort: command: SELECT => socket error: EOF

2 participants