Repository navigation
The app aborts at launch: the import schedule spawns outside a Tokio runtime #311
Description
Problem
The desktop app aborts at launch. crates/asterism-ui/src-tauri/src/lib.rs calls asterism_core::application::ImportSchedule::spawn inside Tauri's setup hook. That hook runs on the main thread, outside any Tokio runtime. ImportSchedule::spawn (crates/asterism-core/src/application/import_scheduler.rs) starts its loop with a bare tokio::spawn, which panics:
crates/asterism-core/src/application/import_scheduler.rs:110:20:
there is no reactor running, must be called from the context of a Tokio 1.x runtime
The panic happens inside tao's did_finish_launching callback. It cannot unwind there, so the process aborts with SIGABRT before a window appears.
The call came in with 8f1b1cf ("Give an import an interval, and a source's wait somebody to hear it", 2026-09-14). The other async work in the same setup already goes through tauri::async_runtime (block_on for state::init, tauri::async_runtime::spawn for the serve tasks), which is why only this call fails.
Evidence
just ui-e2eon a branch cut from main at b8a598c: the app aborted during wdio'sonPrepare, and no spec ran.- Launching the same e2e build directly with the same environment reproduced the abort and the panic line above.
- Reproduced in the
wdio-feature build only.just dev,just dogfoodand a release build go through the samesetuppath, so they are expected to abort the same way, but that has not been run. - 8f1b1cf is contained in tag
v0.1.1. Whether the published v0.1.1 download starts has not been checked.
Desired outcome
The app starts, and the import schedule's timer runs, in every build that goes through setup: dev, dogfood, release and the e2e build.
Constraints
- The import schedule keeps its current contract:
ImportSchedule::spawnis called by the serving process and by the test that proves it, and the handle stops the timer when it drops. - Tests that call
ImportSchedule::spawnfrom inside a Tokio runtime keep working unchanged. - The fix is verified by
just ui-e2estarting the app, not only by Rust tests. No Rust test drives Tauri'ssetup, and that is how the abort got past every gate.
Open
- Where the runtime should be entered: at the call site (enter
tauri::async_runtime's handle, or spawn through it), or insideImportSchedule::spawn(take atokio::runtime::Handle, as the other long-lived tasks insetupeffectively do). - Whether a cheap gate should launch the app far enough to run
setup, so a panic there fails CI instead of first showing up inui-e2e. - Whether v0.1.1 needs a note or a follow-up release, once it is known whether the published download starts.
Activity