Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stuck notifications #24392

Open
53 of 83 tasks
Johennes opened this issue Feb 1, 2023 · 154 comments
Open
53 of 83 tasks

Stuck notifications #24392

Johennes opened this issue Feb 1, 2023 · 154 comments
Assignees
Labels
A-Notifications Team: App Z-AirFocus Moving issues from GH to AirFocus purposefully using this tag. Z-Chronic

Comments

@Johennes
Copy link
Contributor

Johennes commented Feb 1, 2023

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.

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 has what we consider a bug when it talks about which thread the root message belongs to, which has been reflected in client code, making it inconsistent with the server implementation (at least on the Synapse server). We have a proposal to fix this bug in MSC4037.

Identifying which thread any message is in

It is sometimes difficult for clients to identify which thread an event belongs to, meaning that a receipt pointing to it is sometimes ignored. We have begun drafting MSC4023 to address this.

Other

Previously, we believed that MSC3981 (recursive relations) would solve some of the problems, but since that MSC does not solve the event-ordering problem (because the events from the /relations API are returned in "topological" order) we no longer believe it is important, except as a performance optimisation.
Code-level causes

Code-level causes

We have found and fixed several bugs in the Element Web code that were caused by an incomplete understanding of the meaning of threaded and unthreaded read receipts. We anticipate that some more exist.

(We believe that the primary reason why we're not seeing the same problems on mobile is that the apps persist events they've received whereas Element Web has to re-fetch from scratch after every launch. As a result, any issue in the unread state logic, strikes again and again. The apps also use a single timeline whereas Element Web maintains one timeline per thread in addition to the main timeline in every room.)

High-level plan of actions

Tasks

We believe a lot of progress can still be made without spec changes. So we're slightly deprioritising work on the MSCs.

New issue inbox

The following is a holding area for newly reported issues that require review. Once reviewed, issues should either be moved to one of the other task lists below or, if not applicable, removed from this epic.

Tasks

  1. A-Notif-Panel A-Notifications O-Occasional S-Major T-Defect X-Regression
  2. A-Notifications A-Threads O-Frequent S-Major T-Defect
  3. A-Notifications T-Defect X-Needs-Investigation
  4. A-Notifications A-Threads O-Occasional S-Major T-Defect
  5. A-Notifications O-Occasional S-Major T-Defect
  6. A-Notifications O-Occasional S-Critical T-Defect
  7. A-Notifications A-Threads O-Occasional S-Major T-Defect
  8. A-Notifications O-Occasional S-Critical T-Defect
  9. A-Notifications O-Occasional S-Major T-Defect
  10. A-Notifications A-Threads O-Occasional S-Major T-Defect
  11. A-Threads O-Frequent S-Minor T-Defect
  12. A-Notifications A-Threads O-Occasional S-Minor T-Defect
    t3chguy
  13. A-Notifications O-Occasional S-Minor T-Defect
    t3chguy
  14. A-Notifications A-Redaction A-Threads O-Occasional S-Minor T-Defect
  15. 1 of 2
    A-Notifications A-Threads T-Task
  16. A-Notifications A-Threads O-Occasional S-Major T-Defect X-Cannot-Reproduce X-Needs-Info
  17. A-Read-Marker O-Uncommon S-Major T-Defect X-Regression
  18. A-Notifications O-Occasional S-Minor T-Defect
    t3chguy
  19. A-Room-List O-Frequent S-Minor T-Defect
  20. A-Notifications O-Frequent S-Minor T-Defect
  21. A-Notifications A-Threads O-Occasional S-Major T-Defect
  22. A-Notifications T-Enhancement Z-GetYourUpdates Z-Labs
  23. A-Notifications O-Occasional S-Major T-Defect
  24. O-Frequent S-Minor T-Defect
  25. A-Notifications O-Frequent S-Major T-Defect
  26. A-Notifications O-Occasional S-Minor T-Defect
  27. A-Notifications O-Occasional S-Major T-Defect
  28. A-Notifications A-Threads O-Uncommon S-Major T-Defect

Tasks not blocked by spec work

Tasks

  1. A-DevTools T-Task
    germain-gg
  2. A-Threads O-Uncommon S-Minor T-Defect
    justjanne
  3. A-DMs A-Notifications O-Frequent S-Major T-Defect Z-MadLittleMods
    germain-gg
  4. A-Notifications O-Frequent S-Major T-Defect Z-MadLittleMods Z-Synapse
  5. A-Notifications O-Frequent S-Major T-Defect
    andybalaam
  6. A-Read-Receipts A-Threads O-Frequent S-Minor T-Defect
    weeman1337
  7. A-Notifications A-Read-Receipts A-Threads O-Uncommon S-Minor T-Defect
    weeman1337
  8. A-Read-Receipts
    andybalaam
  9. A-Read-Marker A-Room-List T-Defect
    andybalaam
  10. T-Defect X-Release-Blocker
    weeman1337
  11. O-Uncommon S-Major T-Defect X-Release-Blocker
    t3chguy
  12. A-Notifications T-Enhancement
    dbkr florianduros
  13. 1 of 2
    A-Notifications A-Threads T-Task
  14. A-Reactions O-Uncommon S-Major T-Defect
    t3chguy

Tasks that are related to or dependent on spec work

We've written the following MSCs to try and address the root causes in a reliable and performant way:

Tasks

  1. A-Notifications T-Task
    andybalaam
  2. A-Threads O-Occasional S-Minor T-Enhancement
    clokep
  3. A-Notifications O-Frequent S-Major T-Task Team: App
    justjanne
  4. A-Threads O-Occasional S-Minor T-Defect
  5. A-Notifications A-Threads O-Frequent S-Major T-Defect
  6. A-Notifications O-Frequent S-Major T-Defect
  7. A-Notifications A-Threads O-Occasional S-Major T-Defect
  8. A-Notifications O-Frequent S-Minor T-Defect
  9. A-Notifications A-Threads O-Occasional S-Major T-Defect
  10. App: web
  11. A-Relations-Endpoint A-Threads O-Occasional S-Minor T-Task roadmap
  12. O-Frequent S-Major T-Defect
    t3chguy
  13. A-Notifications O-Uncommon S-Major T-Defect

Issues that are related but out of scope

Time sheeting

WEB: Stuck notifications

@Johennes
Copy link
Contributor Author

Johennes commented Mar 7, 2023

Descoping #24373 as this doesn't have the same level of severity as the other issues.

@Johennes
Copy link
Contributor Author

As mentioned in the issue description, the remaining bugs will require a spec change. We're currently in the process of drafting the MSC but it'll, unfortunately, be more involved than just a simple client-side bug fix.

@jplatte
Copy link

jplatte commented Mar 17, 2023

I don't think that is true. If you look at the comments in #24595, you will find some from rooms where threads were never used and IME clearing cache often fixes these issues.

@Johennes
Copy link
Contributor Author

We're focusing on the most prominent problems first which are in the interplay of threads and other relations. There may be further issues beyond that.

@AlBundy33
Copy link

I had the same issue in some rooms.
Because I don't participate that much in this rooms I tried to write a test-message and it seems that the stuck notifications are gone.

@Johennes
Copy link
Contributor Author

@8227846265 the threads-related stuck notification issues are blocking on matrix-org/matrix-spec-proposals#3981.

@Johennes
Copy link
Contributor Author

We've completed initial implementations for it last week and are now starting to prepare for testing it. Unfortunately, it'll still take some more time to get this landed due to the nature of the spec process.

@leonardehrenfried
Copy link

@Johennes Thanks for this explanation. If there is an environment where a regular user could help test it, I'd love to hear about it.

@Johennes
Copy link
Contributor Author

Thanks @leonardehrenfried. We will most likely be enabling it on beta.matrix.org as to not impact regular users but you can sign-up for a separate account there if you want to help testing.

@alexander-potemkin
Copy link

@Johennes , thanks for the explanation indeed! How soon it could be expected to land to the self hosted solutions?

@Johennes
Copy link
Contributor Author

I'd expect the initial PRs (matrix-org/synapse#15315 & matrix-org/matrix-js-sdk#3248) to land this week.

@leonardehrenfried
Copy link

leonardehrenfried commented May 2, 2023

For everybody subscribed to this ticket: the backend and frontend PRs have been merged now so I expect a rollout quite soon.

(I'm not an Element/Matrix employee, just an interested user.)

@Johennes Johennes changed the title Epic: Fix stuck notifications Stuck notifications May 4, 2023
@Johennes Johennes changed the title Epic: Fix stuck notifications Stuck notifications May 4, 2023
@Johennes
Copy link
Contributor Author

@8227846265 we have one more fix in the making that doesn't depend on the MSC (#25196) and should land soon. If that one doesn't help your case, we'd be interested to hear more details about your particular error scenario.

@leonardehrenfried
Copy link

leonardehrenfried commented Feb 7, 2024

Even this one chat that I couldn't mark as read for ~ 1 year doesn't have a notification anymore.

@j-nava
Copy link

j-nava commented Feb 7, 2024

I've been using develop.element.io for quite a while now and I can also attest that it's getting better and better. I can't wait for this to be completely fixed so I can convince more people to join my little community of friends. 😃

Keep up the good work!

@MTRNord
Copy link
Contributor

MTRNord commented Feb 7, 2024

Seems like since the latest changes I am back to notifications that cant be dismissed on any device. Only a clear cache works. This affects both ele-web and ele-android. So I wonder if its actually synapse causing it this time around 🤔

@benjaoming
Copy link

@MTRNord

Seems like since the latest changes

Can you be more clear about which changes you refer to? In the comments immediately before yours, people are reporting success from develop.element.io so it's important to know if you are having a contradicting experience with the exact same version of Element.

@simonmichael
Copy link

When will the develop.element.io fixes be rolled out in Element desktop and mobile and Element X production/testflight ?

@MTRNord
Copy link
Contributor

MTRNord commented Feb 7, 2024

@MTRNord

Seems like since the latest changes

Can you be more clear about which changes you refer to? In the comments immediately before yours, people are reporting success from develop.element.io so it's important to know if you are having a contradicting experience with the exact same version of Element.

I dont really have an exact commit but it happened to start like that after the crypto upgrade on friday(?) on develop while being on fosdem.

@ajkessel
Copy link

Still experiencing this problem daily in multiple rooms with latest develop.element.io as well as the regular web/desktop release and on iOS Element from TestFlight, using Synapse 1.101.

What's really perplexing is how random it is. Unread notifications show up in random old threads that haven't been touched for a while. There seems to be no precipitating event or rhyme or reason as to what triggers the notification.

Usually, "mark all as read" clears it now, at least temporarily, which is some progress.

Is there any client- or server-side logging I could do to try to isolate the cause more systematically?

@iyanmv
Copy link

iyanmv commented Feb 15, 2024

Maybe someone can do a quick update about the test cases? @florianduros ?

@florianduros
Copy link
Member

@iyanmv #25449 we closed the issue about the test cases. We assume that we fixed the existing tests and we are satisfied with the current tests. Of course, when we are fixing bus around notifications we are adding new tests.

@jo-so
Copy link

jo-so commented Feb 27, 2024

My original report #8941 was about rooms flagged as having new messages after login or cache reset, but they don't have. This issue was closed in favour of this one, but yesterday, I've logging in on a new session and still got stale room notifications. Does anything happen to this issue?

@mutantcornholio
Copy link

mutantcornholio commented Feb 27, 2024

After each time I restart Element, I have to go over 10-15 chats, to mark everything as read. A lot of times, the chats are half a year old.

I feel like it's connected to the fact that messages are being loaded when I click on the conversation, not when I open Element, but that's just a guess.

@mutantcornholio
Copy link

Also, opening chats for the first time after restarting element, when the messages are loaded, marks some of the loaded ancient messages from threads as unread.

@mutantcornholio
Copy link

Also, opening chats for the first time after restarting element, when the messages are loaded, marks some of the loaded ancient messages from threads as unread.

One more thing that I've noticed, is a lot of times the ancient messages are stuff like Alice invited Bob, or Alice changed the power level of Bob from Default to Admin, or Alice made the room invite only. Happens far more often in comparison to active chats, where people actually send messages.

@ajkessel
Copy link

Has progress stalled? I've had the same stuck unread notifications for several months now, both on every production release of Element as well as running bleeding edge from develop.element.io. It does seem to be the same rooms/old messages that consistently show as unread. Is there anything I can do as an end-user to troubleshoot the circumstances, particularly where the issue is reproducible at least for some fraction of the time?

@mutantcornholio
Copy link

Any update?

@JMoVS
Copy link

JMoVS commented Aug 14, 2024

Is there still work on threads becoming unread again and again all the time? Happens quite frequently to me nowadays

@MTRNord
Copy link
Contributor

MTRNord commented Aug 14, 2024

Is there still work on threads becoming unread again and again all the time? Happens quite frequently to me nowadays

I also have this. In foundation room I get a loud ping for a mention in a thread each time a new message is added to the room. Its annoying me.

@dreirund
Copy link

Is there still work on threads becoming unread again and again all the time? Happens quite frequently to me nowadays

I have this, too.

@HelderFSFerreira
Copy link
Contributor

I have more than 30 rooms stuck notifications.

Mark everything a read does not work. Let me know if I should provide any logs.

@JMoVS
Copy link

JMoVS commented Aug 30, 2024

are there more logs required or anything? This issue has been around for more than a full year now and recently progress seems to have stalled

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Notifications Team: App Z-AirFocus Moving issues from GH to AirFocus purposefully using this tag. Z-Chronic
Projects
None yet
Development

No branches or pull requests