Stuck notifications: Reacting to a not-latest message in a thread causes a stuck notification

[turt2live]

Steps to reproduce

1. See a thread with many messages in it (no need for explicit participation)
2. React to one of the messages in the thread, that isn't the latest message
3. Room goes from read to unread
4. Scroll down on the main timeline, even if already scrolled down, with the thread open
5. Room resets to read

Outcome

What did you expect?

For a reaction to not cause the room to go unread (as I would have sent the latest event in the room).

What happened instead?

The room was marked as unread. Switching rooms back & forth, opening and closing the thread, etc did not clear the notification: only forcefully scrolling in the main timeline.

Operating system

Windows 10

Application version

Nightly (2022-12-14)

How did you install the app?

The Internet

Homeserver

t2l.io

Will you send logs?

Yes

[germain-gg]

I have not been able to reproduce this issue. Tried in both an encrypted and unencrypted rooms.
I suspect that there's a difference in pushrules between our two accounts.

Could you try and refine the steps to repro?

Screen.Recording.2022-12-15.at.08.35.40.mov

[turt2live]

Unfortunately that's as refined as I could get it :(

If it helps, the room was New Vector Internal (encrypted, medium traffic), and I have it set to Mentions Only. I'm not sure if there would have been a badge count or not.

[weeman1337]

I am able to reproduce this with two users:

• A starts a thread
• A posts some message in the thread
• B reacts to any of the message in the middle

→ stuck unread

[justjanne]

The following is only to document the testing that I’ve done on this issue for myself, don’t expect it to be 100% accurate:

• neither the thread that was reacted on nor any of the messages reacted on have not been followed by any own events
• the root of the thread was created by someone else
• the message that was reacted on was created by someone else
• the last message in the thread was created by someone else

but it does not matter whether the thread that was reacted on was the most recently updated thread, or followed by any other thread or any other event. It also does not matter whether the message is the genuinely last message in the thread or not.

It seems to be caused by a synthetic read receipt for a thread being added to the room itself instead of the thread.

I've further investigated the cause, and have determined that https://github.com/matrix-org/matrix-js-sdk/blob/develop/src/models/thread.ts#L204-L206 is at fault. It will generate a synthetic read receipt for thread events regardless of whether threadRootId is set or not. But https://github.com/matrix-org/matrix-js-sdk/blob/develop/src/models/read-receipt.ts#L37 uses threadRootId to determine whether a read receipt should belong to a thread or the main room.

This in turn seems to be caused by MatrixEvent.setThread/Thread.setEventMetadata/Thread.processEvent only being called after this synthetic read receipt has already been generated.

Possible solutions could be

• not generating synthetic read receipts for events that have no/the wrong threadRootId (https://github.com/matrix-org/matrix-js-sdk/blob/develop/src/models/thread.ts#L204)
• setting the thread id for events earlier in the process of handling them ()
• using a different approach of determining which thread an event belongs to, instead of just m.relates_to with a fallback to a locally set field (https://github.com/matrix-org/matrix-js-sdk/blob/develop/src/models/event.ts#L555)

Additional questions that remain: Is this caused by the original local echo, or the homeservers' remote echo version of the message? Depending on that, there may be an underlying root cause of the thread id not being correctly set earlier on in the process.

EDIT: It’s definitely the handleRemoteEcho, specifically https://github.com/matrix-org/matrix-js-sdk/blob/develop/src/models/room.ts#L2470 being called before MatrixEvent.setThread/Thread.setEventMetadata, which means the event is in somewhat of a limbo state, where some parts of our code think the event belongs to a thread, and other parts will think it doesn't.