Add choose_relay method in RelayManager#1628
Conversation
|
@va-an if this end up being the approach we go with I think merging in the |
Coverage Report for CI Build 27210341068Coverage decreased (-0.2%) to 85.199%Details
Uncovered Changes
Coverage Regressions18 previously-covered lines in 2 files lost coverage.
Coverage Stats
💛 - Coveralls |
xstoicunicornx
left a comment
There was a problem hiding this comment.
utACK 4ff6a0c
Reviewed and tested the code. Strongly prefer this solution over #1399 . Couple items of feedback that I think are fine left as follow ups if preferred.
One other follow up is that we probably want to add handling for the failed relay scenario, but its not clear to me what sorts of errors should result in the relay being added to the failed relay list. This could be added via the post_request function with something similar to this (note this does not work as is... req.url needs to be converted to Url):
async fn post_request(&self, req: payjoin::Request) -> Result<reqwest::Response> {
let http = http_agent(&self.config)?;
match http
.post(req.url)
.header("Content-Type", req.content_type)
.body(req.body)
.send()
.await
.and_then(|r| r.error_for_status())
.context("HTTP request failed")
{
res @ Ok(_) => res,
e @ Err(_) => {
self.relay_manager
.lock()
.expect("Lock should not be poisoned")
.add_failed_relay(req.url);
e
}
}4544367 to
ac2fd57
Compare
|
Curious if you like the current callsite logic or if you would prefer a async fn post_via_relay<F, T, E>(&self, mut build: F) -> Result<(reqwest::Response, T)>
where
F: FnMut(&str) -> std::result::Result<(payjoin::Request, T), E>,
E: Into<anyhow::Error>,
{
loop {
let relay =
self.relay_manager.lock().expect("Lock should not be poisoned").choose_relay()?;
let (req, ctx) = build(relay.as_str()).map_err(Into::into)?;
match self.post_request(req).await {
Ok(resp) => return Ok((resp, ctx)),
Err(e) => {
tracing::debug!("Request to relay {relay} failed: {e:?}");
self.relay_manager
.lock()
.expect("Lock should not be poisoned")
.add_failed_relay(relay);
}
}
}
}
} |
I like the |
72dd0d4 to
4e256b8
Compare
Co-Authored-By: xstoicunicornx <xstoicunicornx@users.noreply.github.com>
xstoicunicornx
left a comment
There was a problem hiding this comment.
utACK be38713
Reviewed the code and ran test scripts locally, looks good. This greatly simplifies the ohttp key fetching logic and relay selection logic, while disentangling them as separate concerns. It also enforces mandatory randomness in relay selection whenever relay manager is called to provide a relay. Also love to see net negative lines :).
![]()
Just one small nit below.
| //! | ||
| //! `fetch_ohttp_keys` selects a relay at random from the configured list, | ||
| //! `unwrap_ohttp_keys_or_else_fetch` returns user-supplied keys when present, | ||
| //! otherwise selects a relay at random from the configured list, |
There was a problem hiding this comment.
| //! otherwise selects a relay at random from the configured list, | |
| //! otherwise fetches the keys from the config directory using a | |
| //! relay selected at random from the configured list, |
Nit: this comment doesn't read clearly as is
There was a problem hiding this comment.
Going to put this in the followup with @va-an in moving this under the RelayManager
Closes #1391
This could supersede #1399
Instead of having relay selection loose state and each session spawns a new relay manager this PR instead just removes the state from RelayManager istelf by using a
choose_relaymethod which simply randomly selects a new relay per-request. Comes from this #1399 (review).Pull Request Checklist
Please confirm the following before requesting review:
AI
in the body of this PR.