fix(sync): Avoid missed long-poll wake-ups #2068
No reviewers
Labels
No labels
Abandoned
Blocked
Bug
Changelog
Added
Changelog
Missing
Changelog
None
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
Merge
Merge/Manual
Merge/Squash
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
bob the builder
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!2068
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "eleboucher/continuwuity:fix/sliding-sync-reliability"
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?
Avoid missed long-poll wake-ups in
/syncand simplified sliding sync.Previously, a request collected its response before registering its wake waiter. A room update arriving in that gap could be missed, leaving the client waiting until its timeout even though new data was already available. Simplified sliding sync also returned the empty response built before the wake, requiring another client request before the update appeared.
This change subscribes to a per-user generation watch before collecting data. Wakes are retained and coalesced, so updates during collection are observed when the request reaches its wait point. Both sync endpoints re-collect once after a wake; sliding sync returns the newly collected response directly.
Sliding sync delays known-room updates and to-device acknowledgement until the response being returned is selected. A discarded first collection therefore cannot advance connection state or consume to-device events.
This is lighter than the previous database-watcher approach: each request has one per-user receiver, wake-ups coalesce, and a request performs at most two collections. There is no polling or retry loop.
Pull request checklist:
mainbranch, and the branch is named something other thanmain.myself, if applicable. This includes ensuring code compiles.
98192112541f9f85ca4a1f9f85ca4ad514bd1ac8d514bd1ac855e009e93855e009e93852e3255a4152e3255a4174591d24e5@ -111,0 +148,4 @@}}// Typing never wakes a sync loop, so collect it after the long poll settles.I think typing is supposed to wake sync, is it not?
yep you are right sorry