fix(sync): handle wildcard state keys in sliding sync required_state #1379
No reviewers
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 project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!1379
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "wizzeh/continuwuity:fix/sync-wildcard-state-keys"
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?
This pull request fixes a bug in the sliding sync implementation where sending a wildcard state key for an event type would stop all subsequent event types from being sent. The break; in the original code was probably intended to handle cases where a state key includes a wildcard and then some more state keys. In such a case we can stop at the wildcard. However by breaking we exit out of the entire loop and don't process all the event types.
Pull request checklist:
mainbranch, and the branch is named something other thanmain.myself, if applicable. This includes ensuring code compiles.
@ -685,8 +685,15 @@ async fn collect_required_state(required_state_request: &BTreeSet<TypeStateKey>,) -> Vec<Raw<AnySyncStateEvent>> {let mut required_state = Vec::new();let mut wildcard_types: BTreeSet<&StateEventType> = BTreeSet::new();this can be a hashset, since no ordering properties are required
2238a78e0560a3abe752Thank you for the fix! @wizzeh
Sorry for introducing a bug haha.
@titaniumtown wrote in #1379 (comment):
I was actually the one that introduced the bug in my fixup comment 😭 it wasn't your fault
Oh! hahaha