-
Notifications
You must be signed in to change notification settings - Fork 236
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
Fix overly restrictive typeguards in get_rooms_that_allow_join #18066
base: develop
Are you sure you want to change the base?
Conversation
This was causing a bug that was only occuring when the server had modules loaded and there were unjoined space-visible rooms in a hierarchy. This fix is a result of the following investigation: Symptom: new 'space-visible' rooms are not showing up in /hierarchy Reason: because get_rooms_that_allow_join is checking that the allow key is a list, and it's coming back as a tuple https://github.com/element-hq/synapse/blob/develop/synapse/handlers/event_auth.py#L329 -> Reason: when the room is created, the join_rules event calls check_event_allowed - https://github.com/element-hq/synapse/blob/develop/synapse/handlers/message.py#L1289 - which calls event.freeze() which seems to be changing lists to tuples - https://github.com/element-hq/synapse/blob/develop/synapse/module_api/callbacks/third_party_event_rules_callbacks.py#L294 --> so that when the event is being pulled from cache, the allow list is a tuple. But when I restart the server, it gets pulled from the DB and deserialized as a list.
f8d67fc
to
c3e6500
Compare
@@ -326,13 +328,13 @@ async def get_rooms_that_allow_join( | |||
|
|||
# If allowed is of the wrong form, then only allow invited users. | |||
allow_list = join_rules_event.content.get("allow", []) | |||
if not isinstance(allow_list, list): | |||
if not isinstance(allow_list, (list, tuple)): |
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.
We're matching the `(list, tuple)` combo
@@ -326,13 +328,13 @@ async def get_rooms_that_allow_join( | |||
|
|||
# If allowed is of the wrong form, then only allow invited users. | |||
allow_list = join_rules_event.content.get("allow", []) | |||
if not isinstance(allow_list, list): | |||
if not isinstance(allow_list, (list, tuple)): |
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.
@blackmad I've just had a thought on how we can fix all of the cases mentioned in #18117 without having to modify any of the downstream code, see #18103 (comment)
Going to leave this PR until we figure out if that is a viable solution to all of this.
This was causing a bug that was only occuring when the server had modules loaded and there were unjoined space-visible rooms in a hierarchy.
This fix is a result of the following investigation:
Symptom: new 'space-visible' rooms are not showing up in
/hierarchy
Reason: becauseget_rooms_that_allow_join
is checking that the allow key is a list, and it's coming back as a tuplesynapse/handlers/event_auth.py#L329
Reason: when the room is created, the join_rules event creation logic calls
check_event_allowed
-synapse/handlers/message.py#L1289
- which callsevent.freeze()
(insynapse/module_api/callbacks/third_party_event_rules_callbacks.py#L294
) which seems to be changing lists to tuples - so that when the event is being pulled from cache, the allow list is a tuple. But when I restart the server, it gets pulled from the DB and deserialized as a list.Part of #18117
Pull Request Checklist
EventStore
toEventWorkerStore
.".code blocks
.(run the linters)