fix(desktop): wrap get_dev_key invoke in try/catch for release builds#167
Conversation
get_dev_key is only registered in the Tauri command handler for debug builds (#[cfg(debug_assertions)]). In release builds, the invoke() promise rejects with an unhandled error, causing the entire init() function to abort silently — leaving the webview stuck on "Initializing CipherBox..." forever. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
WalkthroughThe change adds try/catch error handling around a dev-key retrieval call in the main application initialization, initializing the devKey variable to null and gracefully handling cases where the command is unavailable in certain build configurations. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
apps/desktop/src/main.ts (1)
51-58: Fix is correct; consider a debug-mode fallback log in the catch.The try/catch properly resolves the release-build regression. One minor gap: the bare
catch {}silently discards all errors, including unexpected IPC failures in debug builds. Ifget_dev_keyfails for a reason unrelated to "command not registered" (e.g., a Tauri IPC misconfiguration during development), the error disappears and the dev has no signal that the--dev-keyflow was skipped unexpectedly.♻️ Optional: surface unexpected errors in debug builds
- try { - devKey = await invoke('get_dev_key'); - } catch { - // Expected in release builds where the command isn't registered - } + try { + devKey = await invoke<string | null>('get_dev_key'); + } catch (err) { + // Expected in release builds where the command isn't registered. + // Log in debug so unexpected IPC failures don't silently drop --dev-key. + if (import.meta.env.DEV) { + console.warn('get_dev_key invoke failed (expected in release builds):', err); + } + }The explicit
invoke<string | null>generic is also slightly clearer than relying on contextual type inference from thedevKeyassignment, though both compile correctly.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@apps/desktop/src/main.ts` around lines 51 - 58, The empty catch swallows all IPC errors; change the invoke call to invoke<string | null>('get_dev_key') and in the catch block log unexpected errors when in debug/dev mode (e.g., check a debug flag or NODE_ENV) so IPC failures during development are surfaced, while still allowing a silent fallback in release builds; reference the devKey variable, the invoke('get_dev_key') call and the surrounding try/catch to locate where to add the conditional debug log.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@apps/desktop/src/main.ts`:
- Around line 51-58: The empty catch swallows all IPC errors; change the invoke
call to invoke<string | null>('get_dev_key') and in the catch block log
unexpected errors when in debug/dev mode (e.g., check a debug flag or NODE_ENV)
so IPC failures during development are surfaced, while still allowing a silent
fallback in release builds; reference the devKey variable, the
invoke('get_dev_key') call and the surrounding try/catch to locate where to add
the conditional debug log.
Summary
get_dev_keyis only registered as a Tauri command in debug builds (#[cfg(debug_assertions)]inmain.rs), but the webview JS calledawait invoke('get_dev_key')without try/catchinit()function — leaving the app stuck on "Initializing CipherBox..." foreverTest plan
--dev-keystill works as before🤖 Generated with Claude Code
Summary by CodeRabbit
Bug Fixes