Thread replies sent from Element Android cause neither unread count nor unread dot on Element Desktop

[Johennes]

Steps to reproduce

1. Create a new private & encrypted room (user A / ED)
2. Invite another user (user A / ED)
3. Post a few messages into the room (user A / ED)
4. Start threads on either of the messages (user B / EA)

Outcome

What did you expect?

A notification count > 0 once for user A (ED) once a thread reply was sent by user B (EA)

What happened instead?

The room did receive neither an unread count nor an unread dot for user A (ED). The threaded messages are visible when going into the room though.

When a new thread was started by user B (EA), no audible notification was played for user A (ED). However, when user B (EA) sent another message into an existing thread, user A (ED) experienced an audible ping – again, without any unread count or dot though.

Operating system

macOS

Application version

Element Desktop nightly

How did you install the app?

https://packages.element.io/nightly/

Homeserver

element.io

Will you send logs?

Yes

[weeman1337]

Can reproduce. Labelled as S-Major because you may miss your messages.

[t3chguy]

Cannot see any diff between replies sent from Android or Web, the reply from Android does seem to pick up the right push rule:

I have a feeling this is a race condition where when the keys arrive after the thread reply, we do not re-evaluate it for push notifications and thus missing them. This seems to be reproducible for me only when Android takes a silly amount of time to send the message, which is did 3 times in a row, the next few times it was far quicker and the problem did not manifest.

Unfortunately my hope of this being related to us categorising events wrong (as an entry point into stuck notifications) seems to have been disproven