Open
Description
This issue has been migrated from #7543.
This is based on a conversation at matrix-org/matrix-spec-proposals#2540 (comment), 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:
- events with no
type
ordepth
- events with bad
depth
values - events in v{1,2} rooms with no event_id/v3+ rooms with an
event_id
- events in v6 rooms that have integers out of range or floats
- events with too many prev_events (Dummy issue #3124)
- etc.
There are three proposed options for this situation:
- silently drop the event. I would argue that we should not be blackholing events, ever: it feels like we'll end up dropping events unexpectedly.
- send an error back in the response, against the event's event_id. This, of course, requires the recipient to parse the json, remove a couple of properties, then re-encode it using canonicaljson (which, you recall, is theoretically impossible) to calculate the event id. That sounds like a tautology to me. It also requires servers which don't even support older room versions to still accept transactions with floats in them. So that leaves us with:
- reject the whole lot.
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.