MailboxNotCachedError infinite retry loop after deleting messages or switching folders — Chrome freezes completely ("Page unresponsive")

[PeViz]

Steps to reproduce

Summary

After certain actions (deleting messages, switching folders), the Mail app retains a stale local message list that no longer matches the state on the server. When it tries to synchronize, it receives an error — but instead of discarding the local state and reloading from the server, it repeats the same failing request indefinitely. This saturates the browser's JavaScript engine and causes the tab to freeze completely, while the server remains idle and a new tab works immediately.

Steps to reproduce

1. Open the Mail app and use it normally (inbox open, messages visible)
2. Delete 3–5 messages from the inbox
3. Switch to another folder (e.g. Trash or Drafts) and back to Inbox
4. Repeat folder switching a few times OR wait for inbox to re-categorize (Today / Yesterday / Last week sections update when new mail arrives)
5. Observe browser console, network tab and Performance recording

Note: the issue is not consistently reproducible on the first attempt — it appears after some combination of the above actions. Once triggered it cannot easily be reproduced again in the same session.

Key observation

Opening Mail in a new browser tab works immediately — the mailbox loads fine and all messages are visible. The performance difference between tabs is dramatic despite identical server conditions, confirming the problem is in stale/corrupted local state in the affected tab.

Browser behavior differences

• Chrome (V8): complete freeze, "Page unresponsive" dialog within seconds of the loop starting
• Safari (JavaScriptCore): same instance, same user — only minor slowdown, UI remains usable

Root cause (observed)

After delete + folder switch, the mailbox is evicted from the local store cache. The syncEnvelopes loop detects MailboxNotCachedError and triggers re-initialization, but re-initialization also fails (400 Bad Request), causing an infinite retry loop with no backoff or recovery path. Promise chains accumulate in memory, saturating the JavaScript event loop and preventing Vue from rendering or responding to user interaction.

The clientWidth TypeError in Thread.vue suggests a race condition where the thread component tries to access a DOM element that no longer exists during the store reset — this may be what initially corrupts the local state.

Additional context

• The affected mailbox is actively used throughout the day — this is NOT a cold-cache / first-load issue (different from Opening a mailbox that isn't cached causes an endless burst of requests #11024).
• ERR_NETWORK_CHANGED appears in Chrome network log during the freeze despite the client being on wired LAN — likely a symptom of the saturated event loop aborting pending connections, not an actual network event.
• A related but distinct bug with the same syncEnvelopes loop has been observed when moving messages to folders (separate issue: "envelope does not exist in unified mailbox" flood).
• The issue has been present since at least Mail 5.8.1 and persists on 5.10.11.

Mail app version

5.10.11

Nextcloud version

33.0.5.1

Mailserver or service

On-premise (Dovecot via LDAP)

PHP engine version

8.4.20

Web server

Apache 2.4.63 (AlmaLinux) with reverse proxy

Database

MariaDB
2.
3.

Expected behavior

Expected behavior

Mailbox remains cached after delete and folder switch operations. Messages load normally. JavaScript event loop remains unblocked.

Actual behavior

Actual behavior

Browser console floods with:

[INFO] mail: Mailbox 93 (undefined) not cached. Triggering initialization
  MailboxNotCachedError: mailbox 93 is not cached

Network tab shows endless repeated requests:

GET /index.php/apps/mail/api/messages?mailboxId=93&limit=20&sort=newest&view=singleton → 400 Bad Request

Also observed in the same session:

POST /index.php/apps/mail/api/mailboxes/3/sync → 409 Conflict
Response: {"status":"fail","data":{"message":"3 is already being synced","type":"OCA\\Mail\\Exception\\MailboxLockedException"}}

And a JavaScript exception:

Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'clientWidth')
    at o.updateParticipantsToDisplay (Thread.vue:263)
    at o.resetThread (Thread.vue:321)
    at o.$route (Thread.vue:216)

Followed by:

parent(iFrameResizer0) noResponse @ 08:07:57.750
No response from iframe

The Mail tab becomes completely unresponsive. Chrome shows a "Page unresponsive" dialog. The only recovery is closing the tab and opening Mail in a new one.

Performance recording comparison

Chrome DevTools Performance tab recorded during the degraded state vs. a fresh tab performing identical actions on the same instance at the same time. Server load was 0.02 throughout.

Metric	Degraded tab	Fresh tab	Difference
INP	7,982 ms	777 ms	10× worse
[unattributed] JS	26,781 ms	8,090 ms	+18,691 ms
1st party JS	5,325 ms	2,827 ms	+2,498 ms
Longest single task	7,823 ms	2,819 ms	2.8× longer

The ~18 seconds of extra unattributed JavaScript in the degraded tab represents promise chains accumulating in memory from the syncEnvelopes retry loop. The server is idle (load 0.02) — the problem is entirely client-side, isolated to the specific tab's Vuex store state.

Mail app version

No response

Nextcloud version

No response

Mailserver or service

No response

Operating system

No response

PHP engine version

None

Nextcloud memory caching

No response

Web server

None

Database

None

Additional info

No response