Sliding sync v5: list ranges always start from 0, breaking sliding window #1444
Labels
No labels
Blocked
Bug
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/E2EE
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Matrix/T&S
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
To-Merge
Wont fix
old/ci/cd
old/rust
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity#1444
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
In handle_lists in src/api/client/sync/v5.rs, the start of every requested range is unconditionally overwritten to 0:
for mut range in ranges {range.0 = uint!(0);range.1 = range.1.checked_add(uint!(1)).unwrap_or(range.1);This means all list ranges are processed as [0, end] regardless of what the client requested.
Expected behavior:
A client requesting ranges
[[20, 49]]should receive only rooms 20–49 from the sorted room list.Actual behavior:
A client requesting ranges
[[20, 49]]receives rooms 0–49. The requested rooms are included, but rooms 0–19 are also unnecessarily processed and returned.Impact:
[[0, 19], [40, 59]]) effectively collapse into[[0, 19], [0, 59]], duplicating work for rooms 0–19