-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Refactor backfilled
into specific behavior function arguments (_persist_events_and_state_updates
)
#11417
Refactor backfilled
into specific behavior function arguments (_persist_events_and_state_updates
)
#11417
Changes from all commits
d6b3fee
c138f8c
67393b8
52e3121
c83148e
96f1fe6
53e5d0b
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 @@ | ||
Refactor `backfilled` into specific behavior function arguments (`_persist_events_and_state_updates` and downstream calls). |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -583,7 +583,8 @@ async def _persist_event_batch( | |
current_state_for_room=current_state_for_room, | ||
state_delta_for_room=state_delta_for_room, | ||
new_forward_extremeties=new_forward_extremeties, | ||
backfilled=backfilled, | ||
use_negative_stream_ordering=backfilled, | ||
inhibit_local_membership_updates=backfilled, | ||
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.
Around that idea, there is a nicety around grouping up the behavior under the Somewhere at the multiple top-levels when we refactor this further, we're going to have to make sure the Wdyt about having a static lookup map: class BackfilledAttributes:
use_negative_stream_ordering = False
inhibit_local_membership_updates = False
other_more_condition = True
extraneous_more_condition = False
different_more_condition = True And it can be used like this. I don't know. I'm not convinced of this usage and haven't figured a good clean way for the await self.persist_events_store._persist_events_and_state_updates(
chunk,
current_state_for_room=current_state_for_room,
state_delta_for_room=state_delta_for_room,
new_forward_extremeties=new_forward_extremeties,
use_negative_stream_ordering=BackfilledAttributes.use_negative_stream_ordering if backfilled else ...,
inhibit_local_membership_updates=BackfilledAttributes.inhibit_local_membership_updates if backfilled else ...,
other_more_condition=BackfilledAttributes.other_more_condition if backfilled else ...,
extraneous_more_condition=BackfilledAttributes.extraneous_more_condition if backfilled else ...,
different_more_condition=BackfilledAttributes.different_more_condition if backfilled else ...,
) 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. There's something to be said for identifying different "classes" of event (in this case, 'backfilled' and, uh, 'normal') with a list of exactly how those classes differ in behaviour. In that case you can just pass the 'class' identifier around rather than a sea of booleans. We do something pretty similar with room versions (see https://github.com/matrix-org/synapse/blob/v1.47.0/synapse/api/room_versions.py#L50 etc) and I don't hate it. That said, I'm yet to be convinced that such a solution isn't over-engineered in this case - if we've only really got a few degrees of freedom here, then booleans for them might be easier. Can I reserve judgement on this? 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. Great comparison to
Totally fine to push this to when we have more a need. Just wanted to throw out the inkling of an idea that the original |
||
) | ||
|
||
await self._handle_potentially_left_users(potentially_left_users) | ||
|
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.
given that these don't have default values, does it necessarily make sense for them to be kw-only args? (Not necessarily asking for a change, just musing)
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'm leaning to keeping it. Keyword-only matches the sole usage already and seems decent to not mix-up the arguments because there isn't a straightforward order from the function name.