Fix overly restrictive typeguards in get_rooms_that_allow_join #18066
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
synapse/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.Pull Request Checklist
EventStore
toEventWorkerStore
.".code blocks
.(run the linters)