Skip to content
This repository has been archived by the owner on Sep 11, 2024. It is now read-only.

Improve room safety in the new room list #4905

Merged
merged 7 commits into from
Jul 7, 2020
Merged

Improve room safety in the new room list #4905

merged 7 commits into from
Jul 7, 2020

Commits on Jul 7, 2020

  1. Wrap handleRoomUpdate in a lock 

    Dev note: this is removed in a later commit
    @turt2live
    turt2live committed Jul 7, 2020
    Configuration menu
    Copy the full SHA
    0b6f744 View commit details
    Browse the repository at this point in the history

  2. Flag & add some debugging

    @turt2live
    turt2live committed Jul 7, 2020
    Configuration menu
    Copy the full SHA
    18df29b View commit details
    Browse the repository at this point in the history

  3. Handle sticky room to avoid accidental removal 

    Plus a bunch of logging.

This fixes a case where switching rooms would cause the last room you were on to disappear due to an optimization where known NewRoom fires would be translated to tag change fires, which wouldn't re-add the room to the underlying tag algorithm.

By tracking the last sticky room, we can identify when we're about to do this and avoid it. 

This commit also adds a check to ensure that we have the latest reference of a room stored as rooms changing from invite -> join change references.

This commit additionally updates the PossibleTagChange handling to be faster and smarter, leading to a more stable generation of the room list. We convert the update cause to a Timeline update in order to indicate it is a change within the same tag rather than having to jump tags. This also means that PossibleTagChange should no longer make it as far as the underlying algorithm.

New logging has also been added to aid debugging.
    @turt2live
    turt2live committed Jul 7, 2020
    Configuration menu
    Copy the full SHA
    4345f97 View commit details
    Browse the repository at this point in the history

  4. Ensure the sticky room changes if the tag changes 

    This fixes a case where a user accepts an invite, which causes a tag change, but the room stays stuck in the invites list. The tag change additionally gets swallowed when the user moves away, causing the room to get lost. 

By moving it when we see it, potentially during a sticky room change itself (though extremely rare), we avoid having the room get lost in the wrong lists. A side effect of this is that accepting an invite puts it at the top of the tag it's going to (usually untagged), however this feels like the best option for the user.

A rare case of a tag change happening during a sticky room change is when a leave event comes in for the sticky room, but because it's come through as a tag change it can get swallowed. If it does get swallowed and the user clicks away, the tag change will happen when the room is re-introduced to the list (fake NewRoom event).
    @turt2live
    turt2live committed Jul 7, 2020
    Configuration menu
    Copy the full SHA
    dd833f4 View commit details
    Browse the repository at this point in the history

  5. Clean up debug logging

    @turt2live
    turt2live committed Jul 7, 2020
    Configuration menu
    Copy the full SHA
    70e5da6 View commit details
    Browse the repository at this point in the history

  6. Remove the lock around the algorithm 

    This isn't needed
    @turt2live
    turt2live committed Jul 7, 2020
    Configuration menu
    Copy the full SHA
    34bd59c View commit details
    Browse the repository at this point in the history

  7. Fix room duplication when the sticky room reference changes

    @turt2live
    turt2live committed Jul 7, 2020
    Configuration menu
    Copy the full SHA
    8739e2f View commit details
    Browse the repository at this point in the history