Problem

ort 2.0.0-rc.10 panics from inside its global OnceLock when GetApi(ORT_API_VERSION) returns NULL — the failing line is expect(\"Failed to initialize ORT API\") at ort-2.0.0-rc.10/src/lib.rs:188. On Windows, that panic bubbled out of Session::builder() inside screenpipe_audio::speaker::create_session, unwound the tokio worker, and showed up in Sentry as SCREENPIPE-APP-9X / 9Y — 42 events from 42 distinct users on screenpipe-app@2.4.160 in ~13 hours, all on Windows 10.0.26100.

Stacktrace from Sentry:

ort::util::OnceLock<T>::try_init_inner
ort::session::Session::builder
screenpipe_audio::speaker::create_session
screenpipe_audio::speaker::models::get_or_download_model
…
panic on thread 'tokio-rt-worker' at lib.rs:188:57: Failed to initialize ORT API

Fix

Wrap the body of create_session in std::panic::catch_unwind and convert the panic payload (&'static str or String) into an anyhow::Error. The retry/recovery loop in speaker/models.rs already handles the Err branch — failed init now degrades to a clean error instead of crashing the runtime.

The change is in crates/screenpipe-audio/src/speaker/mod.rs only. No dependency changes; Cargo.lock untouched. The default panic = \"unwind\" profile is preserved (workspace Cargo.toml has no panic = \"abort\"), so catch_unwind will actually catch.

Verification

cargo test -p screenpipe-audio --lib speaker:: — 15 tests pass, 6 new:

test speaker::tests::catch_panic_into_error_passes_through_ok ... ok
test speaker::tests::catch_panic_into_error_passes_through_err ... ok
test speaker::tests::catch_panic_into_error_catches_str_panic ... ok
test speaker::tests::catch_panic_into_error_catches_string_panic ... ok
test speaker::tests::catch_panic_into_error_simulates_ort_api_init_panic ... ok
test speaker::tests::create_session_returns_err_for_missing_path ... ok

test result: ok. 15 passed; 0 failed

catch_panic_into_error_simulates_ort_api_init_panic panics with the literal string ort raises (\"Failed to initialize ORT API\") and asserts the wrapper turns it into an anyhow::Error containing \"ort session init panicked\" and the original payload.

cargo check -p screenpipe-audio — clean (no new warnings).

Confidence: 7/10

The defensive conversion is unambiguous and tested against the exact panic message. What's harder to prove from this side is the root environmental cause on Windows (likely VC++/ORT DLL version skew vs the bundled binary) — but that's a separate fix; this PR just stops the panic from killing the tokio worker so users can continue running.

auto-generated by issue-solver pipe