Trim metadata publish latency: skip global connection wait, 6s send cap
This commit is contained in:
parent
ad70890efc
commit
cb23a5e32d
1 changed files with 5 additions and 4 deletions
|
|
@ -10,11 +10,9 @@ use crate::relays;
|
|||
use crate::settings::Settings;
|
||||
use crate::vault::{unix_timestamp, StoredProfile, Vault};
|
||||
|
||||
/// How long to wait for relays to accept a connection attempt.
|
||||
const METADATA_CONNECT_TIMEOUT: Duration = Duration::from_secs(5);
|
||||
/// How long to wait for a single relay to accept the metadata event. Relays
|
||||
/// are sent to in parallel, so this caps the whole publish, not each relay.
|
||||
const METADATA_SEND_TIMEOUT: Duration = Duration::from_secs(8);
|
||||
const METADATA_SEND_TIMEOUT: Duration = Duration::from_secs(6);
|
||||
|
||||
/// A safe view of a profile that contains no secret key material.
|
||||
#[derive(Debug, Clone, Serialize, PartialEq, Eq)]
|
||||
|
|
@ -342,7 +340,10 @@ async fn publish_metadata_async(
|
|||
let _ = client.add_relay(url.as_str()).await;
|
||||
}
|
||||
client.connect().await;
|
||||
let _ = client.wait_for_connection(METADATA_CONNECT_TIMEOUT).await;
|
||||
// No explicit wait for connections here: `send_event` waits for each relay
|
||||
// to become writable itself, and the per-send timeout below already bounds
|
||||
// the whole publish. Waiting for *all* relays first would burn the full
|
||||
// timeout whenever a single relay is unreachable.
|
||||
|
||||
// Send to every relay in parallel so one slow or dead relay cannot drag
|
||||
// the whole publish out to (relays x timeout).
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue