mirror of
https://github.com/karatektus/pl_mail.git
synced 2026-10-25 10:04:18 +00:00
Paul LütznerandClaude Opus 5
db43d11ca3
Both reported from the demo's Receive button, which is the clearest case of each: one deliberate event, one deliberate refresh, somebody watching. THE BADGE DID NOT MOVE A counts refresh is rate-limited to one per fifteen seconds, and an event arriving inside that window was DROPPED — the reasoning written there was that "a missed counts update is corrected by the next one, and there is always a next one". True for a mailbox syncing on a timer. False for a person pressing a button: Receive publishes exactly one event, and if it landed inside the window nothing ever came to correct it. It defers to the end of the window now instead of dropping. The burst protection is unchanged — five accounts syncing is still one request. And the timer is per instance, which is the half that took longest to see. There are TWO sidebars on the page, the desktop rail and the drawer, so there are two controllers with their own badges; a single shared slot meant the second to schedule cancelled the first, and only one of them was ever brought up to date. The tracing that found it was "the patch ran, from 3 to 4" printed exactly once against two badges that both read 3. THE LIST FLASHED Rows have morphed for a while, so they animate properly. Everything around them did not: tabs and pagination were assigned over with innerHTML on every refresh, so the tab strip, its underline and its counts were torn down and rebuilt each time. The rows slid in and the furniture blinked, which reads as the list flickering rather than as mail arriving. The comment there said morphing them "would be machinery bought for nothing" because they hold no state, no focus and no identity. Right about state, and it missed the other thing morphing buys, which is the screen not moving. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>