Stuck notification in thread

[robintown]

Steps to reproduce

Unclear, but this is what happened:

1. Go offline
2. Have someone start a thread in a room where you receive notifications, and then edit their threaded message
3. Go online
4. Open the thread

Outcome

What did you expect?

The notification count should go down from 2 to 0

What happened instead?

The notification count went down from 2 to 1, and the thread remained marked as unread in the thread list. Restarting the client was necessary to clear the notification.

Operating system

NixOS unstable

Browser information

Firefox 107.0.1

URL for webapp

develop.element.io

Application version

Element version: c473cb6-react-9914b0bafd23-js-ccab6985ad55 Olm version: 3.2.12

Homeserver

Synapse 1.72.0

Will you send logs?

No

[gaelgatelement]

I reproduced this issue in the Delight room.

The room shield appears as red.

The notification counter appeared as grey. Selecting the thread did not reset the counter.

When talking into the room, it seems that the notification disappeared.

[t3chguy]

One cause of this is when the edit event is the latest thing in the unread thread, I wonder if the load-thread-from-server API doesn't include the edit event and thus it not being in the timeline results in the RR being set on the wrong event (the original event ID rather than the ID of the edit event)

I have show hidden events enabled.

Given how frequent edits are, this will be happening whenever the latest event in a thread is an edit. And entirely destroys productivity by wedging an unread dot on the space, the room and the thread in the room list.

[t3chguy]

The client seemingly has no way to know the real latest event id in the thread as the server doesn't give it a total order list of all the events, only the 1st-order related events (thread responses), edits and other 2nd-order relations are bundled inside the 1st-order relations' unsigned fields.

This issue impacts all users & devices who were not open/online at the time a thread response gets edited, all the while until another response is added to the thread. Based on this and how common edits are, I'd argue most users will see this from every now and then, so this sits just below O-Frequent given it isn't "regularly"

[germain-gg]

This has been regressed caused by matrix-org/matrix-js-sdk#2856

The canContain function in addEventToTimeline calls eventShoudLiveIn, and it does not figure out the threadId. It then incorrectly filters out the m.replace event...

Currently trying to find an appropriate fix for this issue