Stop the badge costing portal members a request a minute

Fixkamo-internal
Shipped
August 6, 2026 at 10:50 PM UTC
Author
kamo
Commit
9917100

Three things, all of them about who the count is for. THE PROVIDER GATES ON THE SAME CONDITION AS THE BUTTON. It mounts in the root layout for every authenticated session, and NavTop hides the signature button unless getMemberType() is TEAM_MEMBER — so a portal member was opening a STOMP subscription and re-seeding over REST every 60 seconds for a number that is 0 by construction and that they can never see. The gate is now one exported function, legalBadgeAppliesTo, read by both call sites: a second copy of the comparison would have drifted silently, leaving the button hidden while the traffic carried on. The provider cannot be conditionally mounted, so it blanks memberId instead, which the seed, the interval and the subscription all key off already. THE COUNT IS CLEARED WHEN THE IDENTITY CHANGES. God-mode sudo and a session switch both change the member under a mounted provider, and the seed that corrects the badge is a round trip away. Painting the previous person's outstanding-package count on this one's chrome is a disclosure, not a flicker. AND THE IN-FLIGHT SEED CANNOT UNDO THAT CLEAR. The request outstanding across the switch went out under the PREVIOUS member's cookie, so it resolves with the previous member's count and the id captured in its own closure still matches it — parsePendingCount accepts it and repaints exactly the number that was just cleared. A ref holding the live identity gates the write. 825 vitest / 68 files, tsc clean, both guards green.

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