proc_metrics::sample_self supports Linux and macOS (this is

Error message

proc_metrics::sample_self supports Linux and macOS (this is a {} build)

What it means

proc_metrics::sample_self builds a ProcSample from /proc on Linux and rusage on macOS; every other target compiles a stub that bails loudly with the build's OS name rather than fabricating a reading (the source comment says exactly that). Because the desktop product also ships Windows, Windows builds take this stub — the failure is intentional honesty, not an accident.

Source

Thrown at src/openhuman/platform/proc_metrics/mod.rs:284

    Ok(ProcSample {
        rss_kib: usage.ri_resident_size / 1024,
        pss_kib: 0,
        private_clean_kib: 0,
        private_dirty_kib: 0,
        vm_hwm_kib,
        threads,
        binary_size_bytes,
        // `ri_user_time` / `ri_system_time` are nanoseconds on Darwin.
        cpu_user_ms: usage.ri_user_time / 1_000_000,
        cpu_system_ms: usage.ri_system_time / 1_000_000,
        open_fds,
    })
}

/// Unsupported-platform stub — fails loudly rather than fabricating a reading.
#[cfg(not(any(target_os = "linux", target_os = "macos")))]
pub fn sample_self() -> anyhow::Result<ProcSample> {
    anyhow::bail!(
        "proc_metrics::sample_self supports Linux and macOS (this is a {} build)",
        std::env::consts::OS
    )
}

/// Median of a slice of `u64`, averaging the two middle values for even counts.
/// Empty input yields zero.
fn median_u64(values: &[u64]) -> u64 {
    if values.is_empty() {
        return 0;
    }
    let mut sorted = values.to_vec();
    sorted.sort_unstable();
    let mid = sorted.len() / 2;
    if sorted.len() % 2 == 1 {
        sorted[mid]
    } else {
        // Average without overflow.

View on GitHub (pinned to 7491200858)

Solutions

Gate the caller: skip the metric on unsupported platforms (cfg or a runtime OS check) — observability must not be load-bearing there.
If the metric matters on Windows, contribute a platform implementation upstream rather than faking a value.
Fall back to coarse std APIs where an approximation is acceptable.

Example fix

// before
let sample = proc_metrics::sample_self()?;

// after — degrade to "no sample" on unsupported platforms
let sample = match proc_metrics::sample_self() {
    Ok(s) => Some(s),
    Err(e) if e.to_string().contains("supports Linux and macOS") => None,
    Err(e) => return Err(e),
};

Defensive patterns

Strategy: fallback

Validate before calling

fn proc_metrics_supported() -> bool {
    matches!(std::env::consts::OS, "linux" | "macos")
}

if proc_metrics_supported() {
    let sample = proc_metrics::sample_self()?;
    // ...
}

Type guard

fn can_sample_self() -> bool {
    matches!(std::env::consts::OS, "linux" | "macos")
}

Try / catch

Match the 'supports Linux and macOS' message and treat it as a known-unsupported condition (skip the sample); propagate genuine read failures on supported platforms — those indicate a real problem.

Prevention

cfg-gate metric wiring per target so unsupported builds never call sample_self.
Keep dashboards tolerant of absent proc metrics.
Do not route product decisions through sample_self on Windows.

When it happens

Trigger: Calling proc_metrics::sample_self() in a build targeting windows — or any non-linux/macos target such as freebsd, android, or wasm — e.g. a Windows desktop build wiring the health/proc-metrics panel, or cross-target integration tests.

Common situations: Windows desktop builds surfacing health dashboards; CI matrices iterating all three desktop OSes; ports to non-supported platforms.

Understand the failure class

Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.

Related errors

AI-assisted analysis of tinyhumansai/openhuman@7491200858 (2026-08-17). Data as JSON: /api/errors/1a2a4c7fd655318c. Report an issue: GitHub.