tinyhumansai/openhuman · info

openhuman sentry-test intentional panic

Error message

openhuman sentry-test intentional panic

What it means

This is not a product fault: `openhuman sentry-test --panic` deliberately panics with this exact message to verify the crash-reporting integration captures native panics. The command first prints the captured event_id on stdout, flushes Sentry (warning after a 5s timeout), and only then panics - so a non-zero exit and a panic backtrace afterwards are expected observable results. In a build compiled without the crash-reporting feature the subcommand instead reports unavailability.

Source

Thrown at src/core/cli.rs:311

    });

    let event_id = sentry::capture_message(&msg, sentry::Level::Error);

    if let Some(c) = client {
        if !c.flush(Some(std::time::Duration::from_secs(5))) {
            eprintln!(
                "[sentry-test] WARNING: flush timed out after 5s — event may not have reached Sentry."
            );
        }
    }

    println!("{event_id}");

    if do_panic {
        eprintln!(
            "[sentry-test] Triggering panic as requested — the panic integration should capture it."
        );
        panic!("openhuman sentry-test intentional panic");
    }

    Ok(())
}

/// Disabled-build stand-in for [`run_sentry_test_command`]. Same signature as
/// the `crash-reporting` version; reports that the probe is unavailable in a
/// build compiled without the feature rather than pretending to succeed.
#[cfg(not(feature = "crash-reporting"))]
fn run_sentry_test_command(_args: &[String]) -> Result<()> {
    Err(anyhow::anyhow!(
        "sentry-test unavailable: built without the crash-reporting feature — \
         rebuild with `--features crash-reporting`"
    ))
}

/// Loads key/value pairs from a `.env` file into the process environment.
///

View on GitHub (pinned to 7491200858)

Solutions

1. If intentional, nothing to fix - match the event_id printed on stdout against the event in the Sentry dashboard to confirm delivery.
2. If the '[sentry-test] WARNING: flush timed out' line appears, investigate network egress or the DSN so events are not silently lost.
3. If you only wanted event delivery without the crash, re-run without the --panic flag.

if (args.includes('--panic')) { // intentional crash: run in a disposable subprocess
  expectNonZeroExit = true; }

When scripting `openhuman sentry-test --panic`, spawn it as a subprocess and expect a non-zero exit plus the 'sentry-test intentional panic' message; treat that pair as success, capture the event_id from stdout, and match it in Sentry. Never let it run inside a long-lived process.

When it happens

Trigger: Explicitly running `openhuman sentry-test --panic` to QA the Sentry DSN and symbol pipeline; CI smoke jobs that exercise the crash path end to end; a script accidentally leaving --panic in place when only event delivery was meant to be tested.

Common situations: Verifying Sentry configuration after uploading release symbols (scripts/upload_sentry_symbols.sh); testing the panic hook; the resulting Sentry event later being mistaken for a real crash during triage.

Related errors

• Unknown core RPC error
• Failed to parse service CLI output as JSON: ${err instanceof
• Failed to parse service CLI output as JSON: parsed value doe
• Not running in Tauri
• tui feature disabled at compile time; rebuild with `--featur

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