Stuck notifications
We are experiencing multiple issues in the area of "stuck" notifications and unread markers. Many are related to the way receipts interact with threaded messages. ## Symptoms We are seeing different symptoms of the problem: * "Stuck" unread dots and notification counters: Even when I have read all messages in a room, the room is still marked as unread or having notifications. * Unread dots or notification counters returning on app startup: When I restart the app (or refresh the page on Web) rooms which I have already read re-appear as unread. * Notification counters growing and shrinking spontaneously after entering or scrolling in a room. ## Spec-level causes ### Message ordering Fundamentally, in order to interpret the meaning of a receipt that says "I have read everything up to here", we need to know what order messages are in. This is not clear in the spec, and we propose to make it clear and explicit in [MSC4033](https://github.com/matrix-org/matrix-spec-proposals/pull/4033). In the meantime, Element Web uses a combination of "sync" order (the implicit order of events arriving via a /sync request) and "timestamp" order (using the `ts` property within events). Some of the existing bugs are probably caused by this inconsistency, but it is not clear yet how many: we believe there are also bugs in the implementation that cause additional problems, and this theoretical inconsistency is only the cause of a few problems. ### Which thread the root belongs to The spec h
Posted by Johennes on Feb 1, 2023, 9:03 AM
Tags
Related issues
- 2026 - Microsoft Office 365
- [Ubuntu] `ubuntu-latest` label will use Ubuntu 26.04 in November 2026
- Gamut mapping
- [Codex Desktop] Editing and resending a queued message triggers "App-server queued follow-up no longer exists"
- [Windows] ChatGPT 26.820.60940 fails with "invalid transport in mcp_servers.codex_app"; Beta 26.727.40816 works
- [BUG]: infinite loading of videos
Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments
github (SaaS)
2026 - Microsoft Office 365
[Ubuntu] `ubuntu-latest` label will use Ubuntu 26.04 in November 2026
Gamut mapping
[Codex Desktop] Editing and resending a queued message triggers "App-server queued follow-up no longer exists"
[Windows] ChatGPT 26.820.60940 fails with "invalid transport in mcp_servers.codex_app"; Beta 26.727.40816 works
[BUG]: infinite loading of videos
Restore GPT-5.6 Sol’s 372k Codex context window, or provide an opt-in setting
Codex Desktop for macOS repeatedly triggers `syspolicyd` / `trustd` CPU and memory runaway
Stuck notifications
We are experiencing multiple issues in the area of "stuck" notifications and unread markers. Many are related to the way receipts interact with threaded messages. ## Symptoms We are seeing different symptoms of the problem: * "Stuck" unread dots and notification counters: Even when I have read all messages in a room, the room is still marked as unread or having notifications. * Unread dots or notification counters returning on app startup: When I restart the app (or refresh the page on Web) rooms which I have already read re-appear as unread. * Notification counters growing and shrinking spontaneously after entering or scrolling in a room. ## Spec-level causes ### Message ordering Fundamentally, in order to interpret the meaning of a receipt that says "I have read everything up to here", we need to know what order messages are in. This is not clear in the spec, and we propose to make it clear and explicit in [MSC4033](https://github.com/matrix-org/matrix-spec-proposals/pull/4033). In the meantime, Element Web uses a combination of "sync" order (the implicit order of events arriving via a /sync request) and "timestamp" order (using the `ts` property within events). Some of the existing bugs are probably caused by this inconsistency, but it is not clear yet how many: we believe there are also bugs in the implementation that cause additional problems, and this theoretical inconsistency is only the cause of a few problems. ### Which thread the root belongs to The spec h
Comments (0)
No comments yet. Start the discussion.