Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Sync that runs out of memory leaves the mailbox locked and is retried forever

Aperta
  • Qualcosa non va?
#13,778 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@dillardblom ci sta già lavorando.

Dal 8/10/2026.

  • #13823 di @dillardblom — aperta
  • #13907 di @gvansanden — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
javascript, php
Ambito
backend, frontend

Direzione di ricerca

Start with ImapToDbSynchronizer::sync(), its finally-based lock handling, and the sync-token persistence path; then inspect the 15-second retry in Mailbox.vue and the GET /api/messages and POST /api/mailboxes/{id}/sync entry points. Reproduce the partial sync from the CLI at the reported memory limit if possible. Done should prevent repeated identical retries after failure, preserve usable progress or release stale locks, and make the UI show an error instead of looping.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

1. to develop bug
Describe the bug

When a mailbox sync runs out of PHP memory, the PHP process dies with a fatal error. The finally blocks in ImapToDbSynchronizer::sync() that release sync_new_lock, sync_changed_lock and sync_vanished_lock do not run on a fatal error, so the mailbox stays locked until Mailbox::LOCK_TIMEOUT (300 s) expires.

Meanwhile the web UI keeps loading the envelope list. GET /api/messages returns 409 (MailboxLockedException: … is already being synced) and Mailbox.vue waits 15 s and tries again. As soon as the lock expires, the next POST /api/mailboxes/{id}/sync starts the same sync, which runs out of memory again. The sync tokens are only stored after a successful sync, so every attempt starts from the same point and fails in the same way.

The result is a loop that does not end by itself:

  • The inbox takes a very long time to load, or does not load, because every envelope request waits for the 15 s retry.
  • A PHP fatal error happens every 5 minutes: Allowed memory size of 536870912 bytes exhausted … horde-imap-client/lib/Horde/Imap/Client/Base.php (in _updateCache(), also Data/Fetch.php).
  • The IMAP server sees a new login every 2 seconds from the retrying requests (about 30 per minute instead of 2 or 3).
  • Other requests from the same session report Slow session_start detected.

It stayed like this for over an hour until the sync was run once with a higher memory limit. After that one successful run, the same sync needed 0.4 to 1.7 s and 44 to 71 MB again.

Steps to reproduce

We cannot name the exact trigger. It is probably a rare race condition that mostly shows up with very large mailboxes. Mailboxes of this size are not unusual in companies, though, so the app should be robust against it.

What we saw:

  1. An INBOX with a large number of messages (here about 18,000) on a Dovecot server with CONDSTORE/QRESYNC.
  2. Something (unknown) made the next partial sync process a large set of messages.
  3. PHP's memory limit at 512M (the Nextcloud AIO default).
  4. Mail opened in the browser.
Expected behavior

Record sync progress along the way, and at the very least when the sync crashes, so that the next attempt does not start over from the beginning and end up in an endless loop. For example, fetch changed messages in chunks and store the sync tokens per chunk.

In addition:

  • A sync that keeps failing stops and shows an error instead of being retried in exactly the same form forever.
  • A lock whose process no longer exists does not block the mailbox for another 5 minutes.
  • The UI does not keep a retry loop running without telling the user anything.
Actual behavior

The loop described above. Running the partial sync from the CLI with the same parameters as the browser (20 known ids, partial sync) reproduces the fatal error at 512M. With a 4G limit it succeeds after 82.5 s with a peak of 586 MB.

Mail app version

5.12.2

Nextcloud version

34.0.4 (All-in-One)

PHP version

8.4 (AIO), memory_limit 512M

Mail server

Dovecot 2.4 (DirectAdmin), IMAP with CONDSTORE/QRESYNC

Additional context

The lock timeout, the finally-based unlocking and the 15 s retry in Mailbox.vue are unchanged on main.

Related, but not the same: #13473 (retry loop on MailboxNotCachedError).

Assisted-by: ClaudeCode:claude-opus-5-5 (debugging)

Lingua principale
JavaScript
Stelle
1k
Fork
369
Merge medio
1g 18h
PR unite (30g)
118

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nextcloud/mail

Tutte le issue di nextcloud/mail

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.