Don't re-sort rooms on no-op RoomUpdateCause.PossibleTagChange

[bradtgmurray]

We've been running into some performance issues with large accounts (1800~ rooms) when the m.direct accountData is being pushed to the client in its entirety (1100~ of the rooms are for users in the m.direct list). Digging through the code here it's not super clear to me why we need to propagate the PossibleTagChange update as a Timeline update for each of the individual 1100 rooms, which then causes us to re-sort the rooms 1100 times, especially when no tags have changed. This is a speculative change and it seems to address the issue, but it's not clear to me if it's correct.

Signed-off-by: Brad Murray [email protected]

---

Here's what your changelog entry will look like:

🐛 Bug Fixes

• Don't re-sort rooms on no-op RoomUpdateCause.PossibleTagChange (#7053). Contributed by @bradtgmurray.

Preview: https://6181a27a19170b3bfcb9ff3a--matrix-react-sdk.netlify.app
⚠️ Do you trust the author of this PR? Maybe this build will steal your keys or give you malware. Exercise caution. Use test accounts.

[turt2live]

From looking at the room list store's history, this seems to be legacy safety behaviour bleeding into production code. Prior to the tag diff check, this simply assumed that the room list changed and needed a re-render, but in #4905 this was later changed to see if an operation was needed. As indicated by the logging (later removed) added at the time, the no-op is possible but was still sent through to the algorithm for re-sorting "just in case".

So, tldr, this should be fine. We have a release candidate coming up on Tuesday (if everything goes according to plan), and I'd like to give this maximum testing because the room list hasn't historically been kind to us. I'll merge this after the RC branches are cut to give it a full cycle's worth of testing.

Thanks for fixing this, and spotting it :)