-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Servers may sometimes incorrectly issue 429s #1732
Comments
Meanwhile, disroot.org->matrix.org is seeing the same misbehaviour right now:
|
Right. It looks like the 429s might be coming from the
...config option on the homeserver. When #1733 kicks in, if we get more than 50 concurrent requests stacked up, the server will start 429ing new ones. Given the requests can take hours/days to execute as per #1733, it gives the appearance of 429ing new ones from that server. |
For disroot.org, it looks like this:
|
However, the reason these requests never return seems to be different to #1733. They certainly don't seem to be directly triggering get_missing_events requests which then block. They either get blocked whilst trying to talk to disroot (which has been marked as unavailable due to having #1733 problems of its own)... or due to being blocked on some other stuck federation activity on curbaf. Digging further. |
get_missing_events used to fallback to fetching the missing events individually requesting from every server in the room, one by one.e This could be unacceptably slow, possibly causing #1732
Mjark reckons that they were blocked on the room lineariser for other unrelated get_missing_events activity. Meanwhile we only let 3 transactions execute concurrently from the same host before we start queuing, so to quote Mjark:
Therefore the 429ing here was actually correct behaviour, and i'm going to close this in favour of the main woes in #1733. |
@erikjohnston was seeing servers incorrectly issuing 429s just before Christmas:
I think i just saw this too, with darmstadt spuriously 429'ing arasphere on receiving a backfill request for no obvious reason:
This then looks also to be related to arasphere subsequently blackholing requests from darmstadt entirely.
The text was updated successfully, but these errors were encountered: