A long-running rc.33 daemon reached OOM with roughly 22 GiB resident and 24 GiB swapped. Live inspection found 40 GiB and 10/20 GiB anonymous container mappings; the active worker stack and tracing metadata identified iroh's scheduled path-open retry loop. In iroh 1.2.0 every failed connection requeues the same path, while each retry visits every connection again. Separate control and data connections multiply the queue geometrically. Vendor the published iroh 1.2.0 source and select it with a workspace Cargo patch. Deduplicate retry admission and cap distinct pending paths at 64, evicting the oldest before inserting a new candidate. Keep the current and next retry batches bounded without combining control/data connections or changing wire protocols, identity derivation, authentication or state. Document source provenance, the live evidence and removal conditions. Upstream PR 4551 merged on October 6, but inspection of the official 1.3.0 crate still shows the unconditional enqueue, so that upgrade alone is not a fix. No version bump, release tag or installed-service change. The default workspace suite includes the exact vendored admission module. Three regressions failed with the original enqueue and pass with the fix: repeated failures across connections, duplicate admission at capacity, and 10,000 distinct candidates with bounded length/capacity and FIFO eviction. Transport integration tests continue using real endpoints and encryption. Checks on Linux in nix develop: - cargo fmt --all -- --check - cargo clippy --locked --workspace --all-targets -- -D warnings - cargo test --locked --workspace --all-targets, with only the inherited TSUNAGI_CONTROL_SOCKET removed from the test environment - git diff --cached --check Initial full-suite runs failed six DNS readiness checks because the inherited system socket path overrode their temporary state directories. Clearing that environment variable resolves those failures without changing application code. Root/network-dependent ignored tests and other operating systems were not run.
40 lines
1.6 KiB
Rust
40 lines
1.6 KiB
Rust
//! Default values used in net_report.
|
|
|
|
/// Contains all timeouts that we use in `iroh-net-report`.
|
|
pub(crate) mod timeouts {
|
|
use n0_future::time::Duration;
|
|
|
|
// Timeouts for net_report
|
|
|
|
/// The maximum amount of time, in seconds, the net_report will spend gathering a single report.
|
|
// This is separated from `OVERALL_REPORT_TIMEOUT` to use as a reference
|
|
// in documentation outside of this crate. `OVERALL_REPORT_TIMEOUT` is a
|
|
// duration and rustdoc cannot calculate it at runtime, and so cannot be
|
|
// used directly for documentation purposes.
|
|
pub const TIMEOUT: u64 = 5;
|
|
|
|
/// The maximum amount of time net_report will spend gathering a single report.
|
|
pub(crate) const OVERALL_REPORT_TIMEOUT: Duration = Duration::from_secs(TIMEOUT);
|
|
|
|
/// The total time we wait for all the probes.
|
|
///
|
|
/// This includes the QAD and HTTPS probes, which will all
|
|
/// start at different times based on the ProbePlan.
|
|
pub(crate) const PROBES_TIMEOUT: Duration = Duration::from_secs(3);
|
|
|
|
/// How long to await for a captive-portal result.
|
|
///
|
|
/// This delay is chosen so it starts after good-working QAD probes
|
|
/// would have finished, but not too long so the delay is bearable if
|
|
/// UDP/QAD is blocked.
|
|
pub(crate) const CAPTIVE_PORTAL_DELAY: Duration = Duration::from_millis(200);
|
|
|
|
/// Timeout for captive portal checks
|
|
///
|
|
/// Must be lower than [`OVERALL_REPORT_TIMEOUT`] minus
|
|
/// [`CAPTIVE_PORTAL_DELAY`].
|
|
pub(crate) const CAPTIVE_PORTAL_TIMEOUT: Duration = Duration::from_secs(2);
|
|
|
|
pub(crate) const DNS_TIMEOUT: Duration = Duration::from_secs(3);
|
|
}
|