fix: Apply client-requested timeout to federated key queries #1261
No reviewers
Labels
No labels
Blocked
Bug
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/Federation
Matrix/Hydra
Matrix/MSC
Matrix/Media
Meta
Meta/CI
Meta/Packaging
Priority
Blocking
Priority
High
Priority
Low
Security
Status
Confirmed
Status
Duplicate
Status
Invalid
Status
Needs Investigation
Support
To-Merge
Wont fix
old/ci/cd
old/rust
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
continuwuation/continuwuity!1261
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "nex/fix/key-query"
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?
Also parallelised federation calls in related functions.
Ran pre-commit which will also make main green again.
Pull request checklist:
mainbranch, and the branch is named something other thanmain.myself, if applicable. This includes ensuring code compiles.
@ -532,2 +552,3 @@Some((server, response))}).collect();.then(async |v| v)Why the empty closure?
good question
@ -522,17 +540,22 @@ wherelet request =federation::keys::get_keys::v1::Request { device_keys: device_keys_input_fed };let response = tokio::time::timeout_at(This does have the slight problem of if WIDTH futures hang at the same time and you still have requests remaining you end up with requests with no deadline, so probably having a min and max deadline would be a good idea - although having a min deadline would mean it's possible to overrun the timeout 🤷
Pretty sure WIDTH gets set based on the CPU too
ugh people should just run faster servers /j
good catch
LGTM