The nav badge follows a message being read, instead of waiting for a reload

Fixkamo-internal
Shipped
September 7, 2026 at 9:35 PM UTC
Author
Kamo
Commit
4c48fdc

The badge treated the STOMP socket being UP as proof that counts were being pushed to it, and those are two different questions. EmailService relays the count from NATS onto the member's topic, so a pod whose relay never started serves a flawless WebSocket that carries nothing: `connected` was true, the local refresh listener was therefore never registered, and the badge sat on its one-shot REST number for the rest of the session. Reading a message moved nothing — which is exactly what "it only updates if I refresh the page" is. The hook now reports `pushLive`: a snapshot has arrived since the current socket came up, cleared on every connect as well as every drop, because a fresh socket has proven nothing yet. MailButton gates its own refresh on that rather than on `connected`. The badge's number also stops ranking one source above the other. Preferring the pushed count meant a push that started and then stopped pinned the badge to the last number it managed to send, and no amount of re-reading the mailbox could move it. Both sources write in arrival order instead, and the REST path only reads while the push is not live, so anything it produces is newer. The root cause is fixed in emailservice alongside this — the relay was on a durable NATS consumer, which admits one subscriber, so at two replicas the second pod was refused and relayed nothing. This is the half that makes the badge honest when a push is not arriving, whatever the reason.

All changes

Like what you see shipping?

Every one of these updates lands in your workspace automatically. Start free and watch it grow week after week.

Start Free ForeverView Pricing