[Bug]: Dragging an email to another folder intermittently clears the sidebar folder tree

[Dimaon]

Description

Dragging a single email to a different folder using the sidebar drop target can intermittently leave the mail sidebar with only the built-in Inbox and Scheduled folders. Custom folders disappear from the UI immediately after the drop. Reloading the page restores the full folder tree.

The folders are not deleted; this appears to be a client-side state or synchronization problem.

Steps to Reproduce

1. Use an account with multiple custom mail folders.
2. Drag a single email from one folder and drop it onto another folder in the sidebar.
3. Repeat the operation until the sidebar state fails.

Expected Behavior

The message moves to the destination folder and the complete folder tree remains visible.

Actual Behavior

After a drag-and-drop operation, the sidebar sometimes retains only Inbox and Scheduled while custom folders disappear. Tags remain visible and Inbox may display as empty. Reloading the page immediately restores the complete folder tree.

Bulwark Version

1.8.1

Stalwart Mail Server Version

0.16.6

Browser

No response

Operating System

None

Screenshots / Screen Recording

No response

Relevant Logs or Error Output

No browser-console error was observed when the condition occurred.

Additional Context

Reproduces in Chrome on macOS. The trigger is the drag-and-drop gesture for a single email, not normal navigation. A reload restores the UI immediately. This seems related to client-side mailbox/sidebar state problems reported in #399 and #414, but the symptom here is the complete custom folder tree disappearing after a single drag-and-drop move.

[Dimaon]

Additional finding: this is not limited to drag-and-drop. Opening an email can also trigger the same sidebar failure.

After an SSE event, the client concurrently starts fetchTagCounts → getTagCounts and fetchMailboxes → getAllMailboxes/getMailboxes. Selecting an email adds getEmail; Stalwart then returns 400 jmap:error:limit with limit: "maxConcurrentRequests". When that happens, custom folders disappear from the sidebar until a page reload; no folders are deleted on the server.

Environment:

• Bulwark 1.8.1
• Stalwart 0.16.6
• Chrome on macOS
• Jmap.maxConcurrentRequests was raised from the default to 32 and verified saved, but the error still reproduces.
• Three Bulwark tabs for the same mailbox were open when observed.

Please do not restrict this issue to the drag-and-drop path: the shared root cause appears to be a burst of duplicate mailbox/tag refreshes after SSE events. A client-side request-deduplication or backoff fix would prevent the temporary loss of the folder tree.

[Dimaon]

Confirmed again after raising Jmap.maxConcurrentRequests to 64 and performing a hard reload. The failure still reproduces.

The browser console then reports the same 400 jmap:error:limit / maxConcurrentRequests burst across these independent UI refreshes:

• getThreads via fetchThreadEmailCounts
• getAllMailboxes via fetchMailboxes
• getTagCounts via fetchTagCounts
• getEmails via refreshCurrentMailbox

The Service Worker registration and settings-sync messages are normal. This means raising the server limit is only a temporary mitigation, not a fix: Bulwark can still issue enough concurrent requests to hit it. Please add request deduplication/serialization or backoff around the SSE-triggered mailbox, tag, thread, and email refreshes.