#110 Fallback notification can be permanently swallowed by the auto-refresh race

[Anonymous]

Originally created by: kristofferR

notifications.ts calls notifiedStore.markNotified(...) at schedule time, but delivery happens ≥1500ms later (plus up to 2500ms of avatar rendering). The same scan calls window.__carrierOnNotification?.(), which arms an auto-refresh reload just 4000ms out (auto-refresh.ts) — inside the delivery window. If the reload wins, the notification is never emitted, and after re-prime the persisted store suppresses it forever as a stale replay.

This is distinct from the [#80] delivery gap (Facebook never firing): here Carrier detects the message and then loses it. Fix: move markNotified into the actual emit path, or persist a pending state. Ref [#80].

[Anonymous]

Originally posted by: kristofferR

Fixed in [#137]. Native notifications now carry a reload-safe conversation route: a page-first notification keeps its emitted id and has the route attached when the conversation row pairs — including when the row arrives after the pairing window and the duplicate fallback is deduped — so a click still opens the thread after the auto-refresh reload drops the in-page handler.

[Anonymous]

Ticket changed by: kristofferR

• status: open --> closed