What causes "Read application metadata" in iced-rs/iced?

Trace back to the panic that poisoned METADATA — this is downstream damage

Read application metadata

Error message

Read application metadata

What it means

The `BEACON` client is a LazyLock: the first debug event initializes it by reading METADATA. `.expect("Read application metadata")` panics when the METADATA RwLock is already poisoned. Logging an event from code that itself holds a METADATA guard would self-deadlock instead, because std's RwLock is not reentrant.

Source

Thrown at debug/src/lib.rs:320

        if ENABLED.load(atomic::Ordering::Relaxed) {
            BEACON.log(event);
        }
    }

    #[derive(Debug)]
    pub struct Span {
        span: span::Stage,
        start: Instant,
    }

    impl Span {
        pub fn finish(self) {
            log(client::Event::SpanFinished(self.span, self.start.elapsed()));
        }
    }

    static BEACON: LazyLock<Client> = LazyLock::new(|| {
        let metadata = METADATA.read().expect("Read application metadata");

        client::connect(metadata.clone())
    });

    static METADATA: RwLock<client::Metadata> = RwLock::new(client::Metadata {
        name: "",
        theme: None,
        can_time_travel: false,
    });

    static LAST_UPDATE: AtomicUsize = AtomicUsize::new(0);
    static ENABLED: AtomicBool = AtomicBool::new(true);
}

#[cfg(any(not(feature = "enable"), target_arch = "wasm32"))]
mod internal {
    use crate::core::theme::palette;
    use crate::core::window;

View on GitHub (pinned to 2cffa99b39)

Solutions

Trace back to the panic that poisoned METADATA — this is downstream damage
Call debug::init eagerly at startup so BEACON initializes before concurrency spreads
Recover from poison in the library: `read().unwrap_or_else(PoisonError::into_inner)`
Never emit debug events from inside code holding a METADATA guard (re-entrancy deadlocks std RwLock)

Defensive patterns

Strategy: fallback

Try / catch

// first event may lazily connect the beacon; keep a failure there non-fatal
let _ = std::panic::catch_unwind(|| {
    debug::tasks_spawned(1);
});

Prevention

Call debug::init before the first loggable event so BEACON initializes on the main thread, not lazily
Never emit debug events from code holding a METADATA guard — std RwLock is not reentrant and will deadlock
After any caught panic in a debug build, prefer restarting the process over reusing poisoned globals
Keep beacon (ICED_BEACON_SERVER_ADDRESS) sessions short-lived during development

When it happens

Trigger: The first `log(...)` call (theme change, span finished, task/subscription counts) after METADATA was poisoned by an earlier panic under one of its guards; or re-entrant logging from inside a METADATA read/write critical section.

Common situations: Debug-instrumented apps where a first panic was swallowed by catch_unwind and any later event triggers lazy BEACON initialization; helper code that logs while iterating metadata under a lock.

Related errors

AI-assisted analysis of iced-rs/iced@2cffa99b39 (2026-08-16). Data as JSON: /api/errors/73bf5461a128d840. Report an issue: GitHub.