Description
The Inbox view frequently stops reflecting the actual mail state without any user action — new mail doesn’t appear, and read/unread indicators (the blue dot) don’t clear even when the underlying message state has correctly updated (confirmed via the context menu correctly showing “Mark as Unread” rather than “Mark as Read”). Switching to another mailbox (e.g. Drafts) and back to Inbox immediately fixes the stale view, with no further sync action needed. This suggests the sync layer/local cache is correctly updated, but the mailbox view component isn’t being notified to re-render or re-query when relevant database changes land.
This looks related to prior report #953 / GitHub #2149 (“Mailspring does not refresh when switching to it after a while”), which covers the same view-invalidation symptom in the specific context of deleting messages. This report is broader: the staleness affects new-mail arrival and unread-state display generally, not just post-delete refresh, suggesting a shared root cause in the store-to-view notification path rather than something delete-specific.
To Reproduce…
Steps to reproduce the behavior:
-
Leave Mailspring open and idle (switch away, let time pass), I closed the lid and left it overnight, then reopened and noticed the issue.
-
Receive new mail and/or dismiss/read a message that flips its unread flag
-
Observe: unread dot doesn’t clear and/or new messages don’t appear in the Inbox list, despite the underlying state being correct
-
Switch to Drafts (or any other mailbox) and back to Inbox — view immediately corrects itself
Expected Behavior
Inbox view updates live as mail state changes, without requiring a manual folder switch to force a re-render.
Screenshots
Setup
- OS and Version: macOS Sonoma 14.8.5
- Installation Method: n/a
- Mailspring Version: 1.23.0 (1.23.0)