Skip to content

V3 shell: sync Tauri commands do blocking filesystem work on the main thread #83

Description

@Loufe

From the third rewrite code review (line references at rewrite 75c79c3).

Three commands are declared as sync fn, which Tauri 2 executes on the main thread, yet they do real IO:

  • queue_add_paths (commands.rs:103) calls bridge.queue_add_paths, which runs crfty_engine::scan::expand_inputs (bridge.rs:440): a full breadth-first directory walk with an fs::metadata stat, path hash, and destructive_identity stat per file (scan.rs:43-135). Dropping a large folder tree freezes the UI for the whole walk.
  • import_history (commands.rs:244) reads and parses a file (coordinator.rs:493-499).
  • scrub_logs (commands.rs:252) rewrites every log file in place (logging/mod.rs:360).

The codebase demonstrably knows the rule and applies it selectively: open_path is async precisely so the desktop hand-off runs off the main thread (commands.rs:297-299), and check_for_update uses spawn_blocking (commands.rs:262-272). A native file open gets a worker thread while a recursive disk walk does not; that is inverted.

Secondary: every submit_* command blocks on a driver mpsc round-trip that includes journal append and fsync, and the driver does not service commands mid-compaction, so even cheap commands can stall the main thread behind disk work. Worth deciding deliberately how much of that is acceptable once the three commands above are fixed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions