Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Only restart growing the allRooms list in case of errors #2208

Merged
merged 1 commit into from
Jul 5, 2023

Conversation

bnjbvr
Copy link
Member

@bnjbvr bnjbvr commented Jul 4, 2023

Edit @Hywan: Address #1911.

When the sync has been terminated and restarts (e.g. an app is going from the background to the foreground), then the sliding sync is always restarting in growing mode, independently of the previous state of the sync (error or normal termination). This is something the current sliding sync proxy can't handle nicely, because it prioritizes a change in parameters over the delivery of live data. As a matter of fact, to get a quicker response from the proxy, we can try to only restart in growing mode if we ran into an error (and not if we had a normal termination).

When the sync has been terminated and restarts (e.g. an app is going from the background to the foreground), then
the sliding sync is always restarting in growing mode, independently of the previous state of the sync (error or normal
termination). This is something the current sliding sync proxy can't handle nicely, because it prioritizes a change in
parameters over live data; as a matter of fact, to alleviate the burden of the proxy, we can try to only restart in
growing mode if we ran into an error (and not if we had a normal termination).
@bnjbvr bnjbvr requested a review from Hywan July 4, 2023 11:08
@bnjbvr bnjbvr requested a review from a team as a code owner July 4, 2023 11:08
@codecov
Copy link

codecov bot commented Jul 4, 2023

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (7bcc886) 76.71% compared to head (e8a3061) 76.72%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2208   +/-   ##
=======================================
  Coverage   76.71%   76.72%           
=======================================
  Files         164      164           
  Lines       17646    17648    +2     
=======================================
+ Hits        13538    13540    +2     
  Misses       4108     4108           
Impacted Files Coverage Δ
...rates/matrix-sdk-ui/src/room_list_service/state.rs 94.73% <100.00%> (+0.19%) ⬆️

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

Copy link
Member

@Hywan Hywan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No longer refreshing the all_rooms list when the sync-loop has been terminated is impactful. ElementX for example calls RoomListService::stop_sync() every time the app is backgrounded for 30sec. So once the app is foregrounded, it will continue from where it left. If the app has been backgrounded for, let say 10mn, an important volume of data might be fetched (with a fully loaded room list of 4000 rooms for example).

One may argue that 10mn is enought to make the sliding sync session to expire. In this case, well, yeah, sliding sync will receive an M_UNKNOWN_POS error, which will refresh the list.

Otherwise, if the metrics shows that we are OK with that, why not.

Maybe it's time to share an idea I had since a couple of days:

  • In case of an error: refresh the list with the default batch size, be 50,
  • In case of a termination: refresh the list with a larger batch size, like 200 or even 500.

Would it help or would it not solve the current problem with the sliding sync proxy server?

// Refresh the lists only if our sync ran into an error (in particular,
// when the session was invalidated by the server). Otherwise, keep on
// iterating on the previous list.
if matches!(self, Error { .. }) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the big match can be simplified as is:

        let (next_state, actions) = match self {
            Init => (SettingUp, Actions::none()),
            SettingUp => (Running, Actions::first_rooms_are_loaded()),
            Running => (Running, Actions::none()),
            Terminated { from: previous_state } => match previous_state.as_ref() {
                Error { .. } | Terminated { .. } => {
                    unreachable!("…");
                }

                state => {
                    // Do nothing.
                    (state.to_owned(), Actions::none())
                }
            },
            Error { from: previous_state } => match previous_state.as_ref() {
                Error { .. } | Terminated { .. } => {
                    unreachable!("…");
                }

                Running => {
                    // Refresh the lists.
                    (Running, Actions::refresh_lists())
                }

                state => {
                    // Do nothing.
                    (state.to_owned(), Actions::none())
                }
            },
      };

Thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Follow up here, #2217.

@Hywan Hywan merged commit a0f4060 into matrix-org:main Jul 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants