feat: Server health tracking #2097
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 project
No assignees
5 participants
Notifications
Due date
No due date set.
Blocks
#2090 bug: New atomic state fetch does not appropriately throttle requests for events
continuwuation/continuwuity
Reference
continuwuation/continuwuity!2097
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "nex/feat/server-health-tracking"
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?
The FitnessGram Pacer test is a multistage aerobic capacity test that progressively gets more difficult as it continues. The 20 meter Pacer test will begin in 30 seconds. Line up at the start. The running speed starts slowly, but gets faster each minute after you hear this signal boop. A single lap should be completed each time you hear this sound ding. Remember to run in a straight line, and run as long as possible. The second time you fail to complete a lap before the sound, your test is over. The test will begin on the word start. On your mark, get ready, start.
Real description: Introduces "health tracking" that enables us to mark a remote server as healthy/unhealthy, allowing the server to intelligently decide whether it wants to send a request to a remote, or just skip over it. This should improve the speed of some federation dependent operations, like invites, joins, encryption, and federation transaction sending.
Pull request checklist:
mainbranch, and the branch is named something other thanmain.myself, if applicable. This includes ensuring code compiles.
85064c939044abc4e8dd1734baf440b8576e974f@ -1240,0 +1246,4 @@let backoff_map = self.services.federation.remote_health();if backoff_map.is_empty() {return Err!("No servers in backoff.");this probably should be a write! and an return Ok
@ -25,4 +12,1 @@) -> bool {let min = min.saturating_mul(tries).saturating_mul(tries);let min = cmp::min(min, max);elapsed < minmy single line function?
there's like 5 references I couldn't be bothered refactoring out, I'll do that later
@ -33,0 +83,4 @@/// Marks or updates a remote's health status as unhealthy. If the remote is/// not already marked as unhealthy, a new entry is created. Otherwise, the/// retry count is incremented andand... what?
wdym? the remote is unhealthy if the next retry is after the current timestamp, otherwise it's healthy
there's no and in the docstring either
@ -157,2 +174,3 @@| TransactionStatus::Failed(..) => {panic!("Request that was not even running failed?!")panic!("{}",panic! can do formatting on its own...?
this is load bearing actually
i have no idea how this happened, I don't remember writing it, I remember clippy complaining at some point but then it went away before I looked at it soooo... clippy?
38133db05b7e3e01e731WIP: feat: Server health trackingto feat: Server health trackingJust watched this PR successfully mark a server as being in backoff, with a stale destination, and then successfully re-resolve it after I flushed my DNS resolver's cache (unbound had a stale entry itself) and getting a request from the unhealthy server, leading to it immediately receiving a complete flush of all of my previous messages and encryption keys. Truly brings a tear to one's eye, the continuwuity indefinite federation cache and sender backoff is dead!
Seems like an improvement to me. 🚢 it