mirror of
https://github.com/element-hq/synapse.git
synced 2024-12-14 11:57:44 +00:00
Exclude OOB memberships from the federation sender (#12570)
As the comment says, there is no need to process such events, and indeed we need to avoid doing so. Fixes #12509.
This commit is contained in:
parent
13e4386710
commit
db2edf5a65
3 changed files with 51 additions and 4 deletions
1
changelog.d/12570.bugfix
Normal file
1
changelog.d/12570.bugfix
Normal file
|
@ -0,0 +1 @@
|
|||
Fix a bug introduced in Synapse 1.57 which could cause `Failed to calculate hosts in room` errors to be logged for outbound federation.
|
|
@ -213,10 +213,17 @@ class _EventInternalMetadata:
|
|||
return self.outlier
|
||||
|
||||
def is_out_of_band_membership(self) -> bool:
|
||||
"""Whether this is an out of band membership, like an invite or an invite
|
||||
rejection. This is needed as those events are marked as outliers, but
|
||||
they still need to be processed as if they're new events (e.g. updating
|
||||
invite state in the database, relaying to clients, etc).
|
||||
"""Whether this event is an out-of-band membership.
|
||||
|
||||
OOB memberships are a special case of outlier events: they are membership events
|
||||
for federated rooms that we aren't full members. Examples include invites
|
||||
received over federation, and rejections for such invites.
|
||||
|
||||
The concept of an OOB membership is needed because these events need to be
|
||||
processed as if they're new regular events (e.g. updating membership state in
|
||||
the database, relaying to clients via /sync, etc) despite being outliers.
|
||||
|
||||
See also https://matrix-org.github.io/synapse/develop/development/room-dag-concepts.html#out-of-band-membership-events.
|
||||
|
||||
(Added in synapse 0.99.0, so may be unreliable for events received before that)
|
||||
"""
|
||||
|
|
|
@ -355,6 +355,45 @@ class FederationSender(AbstractFederationSender):
|
|||
if not is_mine and send_on_behalf_of is None:
|
||||
return
|
||||
|
||||
# We also want to not send out-of-band membership events.
|
||||
#
|
||||
# OOB memberships are used in three (and a half) situations:
|
||||
#
|
||||
# (1) invite events which we have received over federation. Those
|
||||
# will have a `sender` on a different server, so will be
|
||||
# skipped by the "is_mine" test above anyway.
|
||||
#
|
||||
# (2) rejections of invites to federated rooms - either remotely
|
||||
# or locally generated. (Such rejections are normally
|
||||
# created via federation, in which case the remote server is
|
||||
# responsible for sending out the rejection. If that fails,
|
||||
# we'll create a leave event locally, but that's only really
|
||||
# for the benefit of the invited user - we don't have enough
|
||||
# information to send it out over federation).
|
||||
#
|
||||
# (2a) rescinded knocks. These are identical to rejected invites.
|
||||
#
|
||||
# (3) knock events which we have sent over federation. As with
|
||||
# invite rejections, the remote server should send them out to
|
||||
# the federation.
|
||||
#
|
||||
# So, in all the above cases, we want to ignore such events.
|
||||
#
|
||||
# OOB memberships are always(?) outliers anyway, so if we *don't*
|
||||
# ignore them, we'll get an exception further down when we try to
|
||||
# fetch the membership list for the room.
|
||||
#
|
||||
# Arguably, we could equivalently ignore all outliers here, since
|
||||
# in theory the only way for an outlier with a local `sender` to
|
||||
# exist is by being an OOB membership (via one of (2), (2a) or (3)
|
||||
# above).
|
||||
#
|
||||
if event.internal_metadata.is_out_of_band_membership():
|
||||
return
|
||||
|
||||
# Finally, there are some other events that we should not send out
|
||||
# until someone asks for them. They are explicitly flagged as such
|
||||
# with `proactively_send: False`.
|
||||
if not event.internal_metadata.should_proactively_send():
|
||||
return
|
||||
|
||||
|
|
Loading…
Reference in a new issue