Mounted once at the app shell root. The first call seeds the list and the cursor without toasting anything; after that it fetches only rows newer than the cursor, so a steady-state poll comes back near-empty. Tab focus and self-initiated actions trigger an immediate refetch.
Also called: notification refresh · how fast do alerts arrive · polling
- 1Poll cadence is a self-rescheduling timeout chain with ±2s jitter and a hidden-tab backoff.
- 2The cursor is the newest created_at the database emitted, passed back verbatim — re-normalising it truncated Postgres microseconds and re-matched the same row on every poll, which meant 'duplicate toasts + chime spam forever'.
- 3A completely full diff page triggers a full re-seed so a burst cannot drop rows past the limit.
- 4Ids already toasted or chimed this session are remembered (capped at 1000) so a re-delivered row can never alert twice.
- 5A window event lets any view force an immediate refresh after a self-initiated action.
The header names the problem: both bell mounts previously ran their own fetch loops, 'so the badge always agrees between them and the app never double-polls'. The first-call rule exists because 'a stale batch after laptop-wake floods the badge, not the screen'.
- Duplicate polling from two mounts
- Cursor precision loss causing endless duplicate toasts
- A wake-from-sleep flood of old toasts
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →