Open clokep opened 4 years ago
@erikjohnston / @richvdh Does this sound like a reasonable summary of that conversation and what needs to be done?
Open questions from my side include:
beware that the term "rejected" is fraught with danger: we tend to use it for the class of events which we accept onto the DAG but do not include in the room state or send to clients (that's useful, because we want to preserve the structure of the DAG where possible). I'm not sure we have a term for the class of events which are too mangled to even add to the room DAG, though I tend to refer to them as "invalid".
/federation/v1/send
. Alright. That clears it up a bit! 👍 I think this would be relatively straightforward then.
This is based on a conversation at https://github.com/matrix-org/matrix-doc/pull/2540#discussion_r427973050, summarized below:
Currently when an incoming federation event is "bad" for some reason it is rejected by returning a 400 error. This is particularly troublesome in endpoints where multiple events are handled at once, as the entire transaction gets rejected.
Reasons an event might be rejected include:
type
ordepth
depth
valuesevent_id
There are three proposed options for this situation:
It is potentially difficult to return a sensible error since (theoretically) you might not even be able to parse the event data and thus it is proposed to silently drop these events for now.