mirror of
https://github.com/matrix-org/matrix-rust-sdk.git
synced 2026-04-25 09:39:34 -04:00
a2dcfa905f
This patch should ideally be split into multiple smaller ones, but life is life. This main purpose of this patch is to fix and to test `SlidingSyncListRequestGenerator`. This quest has led me to rename mutiple fields in `SlidingSyncList` and `SlidingSyncListBuilder`, like: * `rooms_count` becomes `maximum_number_of_rooms`, it's not something the _client_ counts, but it's a maximum number given by the server, * `batch_size` becomes `full_sync_batch_size`, so that now, it emphasizes that it's about full-sync only, * `limit` becomes `full_sync_maximum_number_of_rooms_to_fetch`, so that now, it also emphasizes that it's about ful-sync only _and_ what the limit is about! This quest has continued with the renaming of the `SlidingSyncMode` variants. After a discussion with the ElementX team, we've agreed on the following renamings: * `Cold` becomes `NotLoaded`, * `Preload` becomes `Preloaded`, * `CatchingUp` becomes `PartiallyLoaded`, * `Live` becomes `FullyLoaded`. Finally, _le plat de résistance_. In `SlidingSyncListRequestGenerator`, the `make_request_for_ranges` has been renamed to `build_request` and no longer takes a `&mut self` but a simpler `&self`! It didn't make sense to me that something that make/build a request was modifying `Self`. Because the type of `SlidingSyncListRequestGenerator::ranges` has changed, all ranges now have a consistent type (within this module at least). Consequently, this method no longer need to do a type conversion. Still on the same type, the `update_state` method is much more documented, and errors on range bounds (offset by 1) are now all fixed. The creation of new ranges happens in a new dedicated pure function, `create_range`. It returns an `Option` because it's possible to not be able to compute a range (previously, invalid ranges were considered valid). It's used in the `Iterator` implementation. This `Iterator` implementation contains a liiiittle bit more code, but at least now we understand what it does, and it's clear what `range_start` and `desired_size` we calculate. By the way, the `prefetch_request` method has been removed: it's not a prefetch, it's a regular request; it was calculating the range. But now there is `create_range`, and since it's pure, we can unit test it! _Pour le dessert_, this patch adds multiple tests. It is now possible because of the previous refactoring. First off, we test the `create_range` in many configurations. It's pretty clear to understand, and since it's core to `SlidingSyncListRequestGenerator`, I'm pretty happy with how it ends. Second, we test paging-, growing- and selective- mode with a new macro: `assert_request_and_response`, which allows to “send” requests, and to “receive” responses. The design of `SlidingSync` allows to mimic requests and responses, that's great. We don't really care about the responses here, but we care about the requests' `ranges`, and the `SlidingSyncList.state` after a response is received. It also helps to see how ranges behaves when the state is `PartiallyLoaded` or `FullyLoaded`.