What causes "{err}" in emilk/egui?

Read the panic message to identify the underlying cause (snapshot mismatch vs exceeded max steps)

{err}

Error message

{err}

What it means

Harness::run is the infallible-facing wrapper around try_run: it executes the harness loop and panics with the error message if try_run returns Err. Any harness failure — max steps exceeded, snapshot mismatch, assertion failure — surfaces as this panic. Use try_run instead if you need to handle failures programmatically.

Source

Thrown at crates/egui_kittest/src/lib.rs:442

    ///
    /// Returns the number of frames that were run.
    ///
    /// # Panics
    /// Panics if the number of steps exceeds the maximum number of steps set
    /// in [`HarnessBuilder::with_max_steps`].
    ///
    /// See also:
    /// - [`Harness::try_run`].
    /// - [`Harness::try_run_realtime`].
    /// - [`Harness::run_ok`].
    /// - [`Harness::step`].
    /// - [`Harness::run_steps`].
    #[track_caller]
    pub fn run(&mut self) -> u64 {
        match self.try_run() {
            Ok(steps) => steps,
            Err(err) => {
                panic!("{err}");
            }
        }
    }

    /// When `sleep` is true, each step sleeps for `self.step_dt`.
    /// When `diagnostic` is true, we run extra steps to find [`ExceededMaxStepsError::steps_to_settle`].
    fn try_run_impl(
        &mut self,
        sleep: bool,
        diagnostic: bool,
    ) -> Result<u64, ExceededMaxStepsError> {
        // Once the budget is blown we keep going for a while, purely to find out how many steps
        // would have been needed. The repaint causes are the ones from the moment we blew it.
        let diagnostic_max_steps = if diagnostic {
            config().diagnostic_max_steps()
        } else {
            0
        };

View on GitHub (pinned to 441971a776)

Solutions

Read the panic message to identify the underlying cause (snapshot mismatch vs exceeded max steps)
Re-run with UPDATE_SNAPSHOTS=1 (or =force) if snapshots changed intentionally
Increase max_steps or enable diagnostics if the UI never settles
Switch to try_run() to match on the error and handle failures without panicking

Example fix

// before
let steps = harness.run();
// after
match harness.try_run() {
    Ok(steps) => steps,
    Err(err) => eprintln!("harness failed: {err}"),
}

Defensive patterns

Strategy: try-catch

Validate before calling

// cannot pre-validate; use try_run to check instead of run
if let Err(err) = harness.try_run() {
    eprintln!("harness would fail: {err}");
}

Try / catch

match harness.try_run() {
    Ok(steps) => println!("settled in {steps} steps"),
    Err(err) => eprintln!("harness failed: {err}"),
}

Prevention

Prefer try_run in test harness code where you want diagnostics instead of aborts
Keep snapshots in version control and update them deliberately via UPDATE_SNAPSHOTS
Raise max_steps or disable animations for UIs that take long to settle
Run snapshot tests in a consistent environment (same scale factor/DPI) as capture

When it happens

Trigger: Calling harness.run() when the underlying try_run fails: the UI never settles within max_steps, a snapshot comparison fails in Test mode, or a custom step/timeout error occurs.

Common situations: Snapshot mismatches after intentional UI changes (need UPDATE_SNAPSHOTS=1); animations preventing the UI from settling before max_steps is reached; flaky async UI timing in CI.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

AI-assisted analysis of emilk/egui@441971a776 (2026-09-12). Data as JSON: /api/errors/6297be89ea5fe68f. Report an issue: GitHub.