fix(tauri): prevent CEF init panic on second launch via single-instance plugin#1510
Conversation
…ce plugin The Tauri shell had no single-instance guard, so launching a second instance (auto-start, double-click, deep-link reopen, …) raced into `CefRuntime::init` while the primary still held the CEF cache lock, `cef::initialize` returned 0, and the vendored runtime's `assert_eq!(..., 1)` panicked. This fires across Win10/11 + multiple Linux distros on every recent release (Sentry OPENHUMAN-TAURI-A, 442 events over 8 days, 0 users impacted because the panic is pre-auth). Changes: - Add `tauri-plugin-single-instance` (pinned to the same plugins-workspace rev as the other plugins) and register it as the *first* plugin in `run()`, so a secondary launch focuses the primary via the existing `show_main_window` helper and exits before `Builder::build()` reaches CEF init. - Bump the `vendor/tauri-cef` submodule pointer to pick up `tinyhumansai/tauri-cef#13`, which replaces the opaque `assertion left == right` with a panic that logs the actual return code and `cache_path` — defense in depth for any other CEF init failure mode. Fixes OPENHUMAN-TAURI-A
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThis pull request integrates the ChangesSingle-instance protection feature
Sequence DiagramsequenceDiagram
participant SecondaryProcess as SecondaryLaunch
participant Plugin as tauri_plugin_single_instance
participant App as TauriApp
participant Window as MainWindow
SecondaryProcess->>Plugin: notify_secondary_launch()
Plugin->>App: invoke_callback(redacted_launch_info)
App->>Window: show_main_window()
🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs:
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/src-tauri/src/lib.rs`:
- Around line 1377-1379: The log call in the single-instance handler currently
prints raw args and cwd via the log::info! invocation ("[single-instance]
secondary launch detected, focusing primary (argv={args:?}, cwd={cwd})"), which
can leak tokens; change it to avoid printing raw argv/cwd—e.g., log only safe
metadata such as args.len() and a redacted or canonicalized cwd (or a boolean
indicating presence), or sanitize/deep-link-specific values before logging;
update the log::info! call so it emits something like argv_count and cwd_safe
(no raw contents) instead of printing {args:?} and {cwd}.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: dbbea93b-e95f-41ae-8dbf-9242783b99c6
⛔ Files ignored due to path filters (1)
app/src-tauri/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (3)
app/src-tauri/Cargo.tomlapp/src-tauri/src/lib.rsapp/src-tauri/vendor/tauri-cef
…kage CodeRabbit on tinyhumansai#1510: the single-instance secondary-launch handler logged raw `args` and `cwd`. Deep-link argv frequently carries OAuth codes / magic-link tokens, which would leak into desktop logs and Sentry breadcrumbs. Log only argc and a boolean for cwd presence.
Summary
tauri-plugin-single-instanceas the first plugin in the Tauri shell so a second app launch focuses the primary window and exits before CEF init runs.vendor/tauri-cefsubmodule to pick up fix(runtime-cef): replace assert_eq! in CefRuntime::init with diagnostic panic tauri-cef#13, which replaces the opaqueassertion left == rightpanic inCefRuntime::initwith a logged panic carrying the CEF return code +cache_path.Problem
Sentry
OPENHUMAN-TAURI-A— 442 fatal panics across 8 days, Win10/11 + Linux (Kali, Debian, CachyOS), every recent release (0.53.13 → 0.53.22). 0 users impacted because the panic is pre-auth.Root cause:
app/src-tauri/vendor/tauri-cef/.../lib.rs:2071doesassert_eq!(cef::initialize(...), 1). The shell registered notauri-plugin-single-instance, so launching a second instance (auto-start, double-click, deep-link reopen) raced intoCefRuntime::initwhile the primary still held the CEF cache lock,cef::initializereturned 0, and the assert panicked. The cross-OS, cross-release, pre-auth pattern matches cache-lock contention, not a code regression in any single release.Solution
Two layers, both needed:
tauri_plugin_single_instance::init(...)as the first plugin inrun()(beforetauri_plugin_opener,deep_link, etc.). The plugin acquires a per-identifier lock before any other plugin setup. A secondary launch hands argv/cwd to the primary via the callback (which logs and focuses the main window via the existingshow_main_windowhelper) and exits beforeBuilder::build()reaches CEF init.cache_path, so any remaining CEF init failure (corrupt cache, missing helpers, sandbox denied) lands in Sentry with actionable context instead ofassertion left == right.Plugin is pinned to the same
plugins-workspacerev (c6561ab6…) as the other Tauri plugins via the existing[patch.crates-io]block. Submodule PR: tinyhumansai/tauri-cef#13.Submission Checklist
cargo check --manifest-path app/src-tauri/Cargo.toml.Builder::build()/CefRuntime::initpaths.Fixes OPENHUMAN-TAURI-A(Sentry) — auto-resolves the Sentry issue on merge.Impact
tauri-plugin-single-instanceuses a named mutex on Windows, a Unix domain socket on macOS, and dbus on Linux — all pertauri.conf.jsonidentifier(com.openhuman.app). No collisions with existing infrastructure.Related
AI Authored PR Metadata (required for Codex/Linear PRs)
Linear Issue
Commit & Branch
fix/cef-init-single-instance0e33e619Validation Run
cargo check --manifest-path app/src-tauri/Cargo.toml— clean (pre-existing warnings only).cargo fmton the two touched Rust files.Validation Blocked
command:N/Aerror:N/Aimpact:N/ABehavior Changes
Parity Contract
tauri-plugin-deep-link.Duplicate / Superseded PR Handling
Summary by CodeRabbit
New Features
Chores