The roomlist requires an extra message to reorder & highlight in encrypted rooms since 1.10.x

[benbz]

Steps to reproduce

1. Receive a single message in an encrypted room (DMs appear to be unaffected)
2. No highlighting of the room in the room list and the room isn't reordered. If the room is in a space, the space does not gain a dot
3. Even if the message included a mention the room list is not updated despite an alert being fired
   1. This makes it very difficult to find the room where you've been pinged if you miss the alert
4. Send another message. The room list is reordered and the room highlighted as if the 1st message had just been processed. If the room is in a space, the space now gains a dot
5. This only started happening since upgrading to 1.10.x.. Clearing of the cache has been attempted

Outcome

What did you expect?

Unread messages in encrypted rooms cause the room to be reordered & highlighted as appropriate in the roomlist immediately

What happened instead?

Message previews for the room update, but the room is not reordered and not highlighted in the roomlist until a further message is sent.

Operating system

Ubuntu Linux

Application version

1.10.1

How did you install the app?

Debian

Homeserver

banzan.uk

Will you send logs?

Yes

[turt2live]

I've been seeing this too. I'm unsure what semantics cause a room to behave this way, and visiting the room does not appear to fix it. Below is what I've managed to find so far.

I've had it happen in unencrypted rooms too, though at less frequency. It can affect multiple rooms at a time.

The room list does reorder to accept the message when using importance ordering, but in the idle rooms section.

Read markers and/or receipts are not sent in the background either (thus doesn't appear to be a store losing state).

If the message is a mention, a notification noise is played despite not appearing as such. Unsure on desktop notifications - those are disabled on my machine.

It can happen in web or desktop.

This started happening this week on nightly.

Neither us or synapse have seemingly made changes in the area. I'm the only user on my homeserver.

Things yet to check are:

• Whether the counts in /sync are affected
• Whether the notification state classes are stuck
• Whether push rule evaluation is no longer reliable in web
• Whether reloading the app helps or not
• Whether mobile is affected

Unfortunately I haven't seen any logging on web or synapse to indicate a problem.

[turt2live]

Just for more added context:

• Sometimes a second message fixes it, often it doesn't (in my case)
• Notifications do seemingly appear eventually. After switching spaces and playing with notification levels on unrelated rooms one of my rooms from the starting space upgraded to a mention. The mention was otherwise delayed by about 8.5 hours.

[turt2live]

I can't get subsequent messages to be reliable in the rooms, but I have found that space hopping appears to kick things into working for some reason. It can take a few hops before rooms start to appear as unread.

[germain-gg]

I don't think I can reproduce this issue either. However I was chatting about the problem with James earlier today and I believe some of the changes in https://github.com/matrix-org/matrix-js-sdk/pull/2132/files could have cause some disturbance here.
I've created some async operation in the SyncAPI which could have an effect here? @turt2live it would be good to test that theory together and I can come up with a plan if that theory is proven correct

[turt2live]

@gsouquet that looks quite plausible. Is the way to test it to disable threading in labs and see if it helps?

[germain-gg]

You definitely can do that. But I'm afraid that because I made some of those functions async and have thrown an await in there it will still hit the same issue.
Maybe if you can run the version right before this PR that would help pinpoint whether that's the root of the issue or not.

Regardless I will be playing around with that area and attempt to make it all synchronous as it used to be