-
Notifications
You must be signed in to change notification settings - Fork 190
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
Correctly handle changes to required state config in sliding sync #17785
Conversation
8f03752
to
5e66e98
Compare
for event_type, state_key in db_to_json(row[1]): | ||
state.setdefault(event_type, set()).add(state_key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps, whenever we db_to_json(...)
, we should scrutinize the output. We could add some asserts (or ignore invalid data with logging) to narrow the type to what we expect which gives us better types and we could've caught this earlier.
isinstance(event_type, str)
isinstance(state_key, str)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we could. Though we don't really do it elsewhere and they're covered by tests (and the data types are enforced by the DB).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wasn't this a mistake before that wasn't caught by either?
We previously assumed state_keys
was a list but was just a single value and would have clobbered any required_state
map with multiple state_keys
Co-authored-by: Eric Eastwood <[email protected]>
Fixes #17698
This handles
required_state
changes by checking if new state has been added to the config, and if so fetching and returning that from the current state.This also takes care to ensure that given a state entry S that is added, removed and then re-added that we do not send S down a second time if there have been no changes to S in the current state. This is fine for Rust SDK (as it just remembers all state), but we might decide not to do this behaviour in the MSC. If we decide to always send down S then its easy enough to rip out all the code.