fix: Re-introduce event fetch backoff #2201
No reviewers
Labels
No labels
Abandoned
Blocked
Bug
Changelog
Added
Changelog
Missing
Changelog
None
Cherry-picking
Database
Dependencies
Dependencies/Renovate
Difficulty
Easy
Difficulty
Hard
Difficulty
Medium
Documentation
Enhancement
Good first issue
Help wanted
Inherited
Matrix/Administration
Matrix/Appservices
Matrix/Auth
Matrix/Client
Matrix/Core
Matrix/E2EE
Matrix/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Matrix/T&S
Merge
Merge/Manual
Merge/Squash
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
bob the builder
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!2201
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "nex/fix/state-fetch-backoff"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Some prior versions of continuwuity (I forget when it was removed) had a per-event backoff system that prevented the server constantly asking for the same events it's never going to see. This was removed at some point, likely in #1818, which now means continuwuity does not attempt to slow down when asking for events it isn't allowed to get, resulting in #2090. As I run several servers behind the same reverse proxy that happen to be backfill candidates, I have seen my request rate surge from 20 rps average to 100 rps average, which obviously isn't great.
This PR re-introduces backoff on event fetches using the same algorithm as federation transaction sending.
Fixes: #2090
Pull request checklist:
mainbranch, and the branch is named something other thanmain.myself, if applicable. This includes ensuring code compiles.
84b974579e6e30efb64f6e30efb64f6cfbb41a42@ -485,3 +475,2 @@}debug!(elapsed=?start.elapsed(),"Fetching {target_id} over federation");self.ensure_can_pull_event(&target_id).inspect_err(|e| {Not sure if this warrants a comment explicitly calling it out, but failing the entire fetch routine immediately here is deliberate - from my logs, it looks like the 5 retry attempts are generally wasted, and errors are usually final (e.g. 403), meaning we ended up sending 5 requests per failed event to every backfill remote, exponentially.
If we can't pull a missing auth event at any point, it is impossible for us to safely continue. The old backoff system simply dropped events which couldn't be fetched, which would lead to incorrect behaviour on pdu check 4. If we can't fetch auth events, we can't auth the event, even if only one is missing.
As for why it doesn't matter for prev events - if we are missing some prev events, we won't be able to calculate the state before the incoming event locally, and will fall back to asking the remote server for the state/_ids. From there, we either get the whole state, or atomically fetch using
fetch_and_handle_auth_events, meaning we always have all events necessary to calculate PDU check 5 (unless, of course, FAHAE fails to fetch an event, bailing out the entire thing yet again)@ -664,3 +667,1 @@} else {Some(event_id.to_owned())}(discovered_events.contains_key(event_id)This is inverted. missing_prev now collects the events we already have.
I've got a knack for doing this