-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Faster room joins: avoid blocking when pulling events with missing prevs #13355
Changes from all commits
ad5d75e
ff8f6cf
f7c9a5a
bca5a17
1d48d23
6517210
b879d8c
7d55d88
7870d44
765614f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Faster room joins: skip soft fail checks while Synapse only has partial room state, since the current membership of event senders may not be accurately known. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Faster room joins: avoid blocking when pulling events with partially missing prev events. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -82,13 +82,15 @@ async def get_state_group_delta( | |
return state_group_delta.prev_group, state_group_delta.delta_ids | ||
|
||
async def get_state_groups_ids( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. as a random point for future reference: there is a convention that the subject line of a git commit message should be limited to 50 characters. That helps avoid this sort of thing: There's an art to writing such a pithy summary, of course. In this case I would probably just say:
... and put "so that it can return partial state" in the body of the commit message. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. interesting, I wasn't aware that the subject line had a shorter recommended length. Up until now I've been using a limit of 72 characters in merge commits (and ignoring it in commits that get squashed, like the one above). 50 characters certainly makes things tricky! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah, the problem comes when we're doing a commit-by-commit review: it's much nicer if there's a pithy summary for each commit. It's certainly not worth stressing overmuch over though.
Indeed. github actually seems to truncate at 66 chars, so that seems a more reasonable compromise. |
||
self, _room_id: str, event_ids: Collection[str] | ||
self, _room_id: str, event_ids: Collection[str], await_full_state: bool = True | ||
) -> Dict[int, MutableStateMap[str]]: | ||
"""Get the event IDs of all the state for the state groups for the given events | ||
|
||
Args: | ||
_room_id: id of the room for these events | ||
event_ids: ids of the events | ||
await_full_state: if `True`, will block if we do not yet have complete | ||
state at these events. | ||
|
||
Returns: | ||
dict of state_group_id -> (dict of (type, state_key) -> event id) | ||
|
@@ -100,7 +102,9 @@ async def get_state_groups_ids( | |
if not event_ids: | ||
return {} | ||
|
||
event_to_groups = await self.get_state_group_for_events(event_ids) | ||
event_to_groups = await self.get_state_group_for_events( | ||
event_ids, await_full_state=await_full_state | ||
) | ||
|
||
groups = set(event_to_groups.values()) | ||
group_to_state = await self.stores.state._get_state_for_groups(groups) | ||
|
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.
should we check that
partial_state
is false?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.
sure, keeping in mind that it won't catch the "calculate-the-state-yourself" case. I can't think of how to handle a second partial state apart from raising an exception.
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.
sorry yes, I'd envisaged raising an exception, on the grounds we could give a clearer idea of what's going wrong.
But if you'd expect it to behave correctly (ish) in the case where we've rejoined, then I guess that's not appropriate and we should just leave this.
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.
I've yet to figure out what happens when we rejoin (not that we can even leave right now!) so am happy to raise an exception.