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

Abierto
  • ¿Algo no está bien?
#13,778 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@dillardblom ya está trabajando en esto.

Desde el 8/10/2026.

  • #13823 de @dillardblom — abierto
  • #13907 de @gvansanden — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript, php
Área
backend, frontend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)

Lenguaje dominante
JavaScript
Estrellas
1.1k
Forks
373
Merge medio
1 d 4 h
PR fusionados (30 d)
99

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nextcloud/mail

Todos los issues de nextcloud/mail

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.