- Shipped
- 19 Agosti 2026, 06:40 UTC
- Author
- kamo
- Commit
- f2ca4f3
Opening /messages showed the "email isn't available / you have no mailbox" panel for a moment on nearly every visit, then replaced it with the member's real inbox. useEmailAvailability reports `available: false` for the whole of its two lookups, so `available` only means anything once `loading` is false. The boot gate read it without that check. 1a050fb6 let a tab holding a cached page skip the boot skeleton — correctly, it has real mail to draw — but the very next line was `if **************** so skipping the skeleton meant falling straight into the panel instead of into the inbox, and staying there until the provider fetch and the mailbox probe both landed. That commit's own comment says the panel "still takes over" only if things resolve unavailable; this is what makes that true. It went unnoticed because it needs a snapshot to trigger: the first visit ever behaves, every visit after it does not. Both branches are one decision, so they are one function now — mailboxBootView, where `unavailable` is a resolved answer and never a waiting one, under test. The nav's Compose entry had the same read. It stays disabled while resolving, since enabling it optimistically could open a compose that cannot send, but it no longer captions that with a generic tooltip telling every member their mailbox is missing.