Handle microphone init failure without aborting#945
Conversation
Return recorder init errors instead of panicking/aborting in the worker thread and reset UI state when recording start fails. Refs cjpais#436
|
@ferologics have you tested this yourself to verify? Just want to make sure. Also do you know if the UI visibly says anything about this failure case? |
|
@cjpais i wasn't able to make handy run locally from source (ref) so i couldn't test. I came across the crash due to having disabled microphone globally via settings. Tried to make this change isolated to that, not touching any UI. Onboarding / in-app hints about disabled mic could made be better tho. Right now when the crash happens it briefly shows the recording UI and then it disappears, no info in the app / anywhere about it. |
|
re: the microphone access denied bit -- it comes directly from my local agent. i had it check the crash log, look at current system settings configuration and patch that particular case in handy. |
|
Got it, I am going to push some changes for the UI I think. Let's get your build env fixed |
|
Tested locally now. Repro:
Result:
So the crash-path fix is working on my machine now. Current UX is much better than before: the recording UI briefly appears and then resets instead of aborting the app, and the PR's UI follow-up now propagates the error to the frontend. I think there is still room for polish in a follow-up (for example a more explicit microphone-blocked message/icon), but the main bug here appears fixed. |
|
|
I would have expected the error to surface closer to the recording indicator / overlay, so I initially missed it. That said, I think this is fine for this PR: the crash is fixed, the error is handled, and there is now a visible path for surfacing it. A more contextual microphone-blocked warning could be a separate follow-up if we want to polish it later. |
|
Thank you for this! I suspect it may also fix: #475 |
* Handle microphone start failures without aborting Return recorder init errors instead of panicking/aborting in the worker thread and reset UI state when recording start fails. Refs cjpais#436 * prop errors to ui * format * Add missing recording error translation keys --------- Co-authored-by: CJ Pais <[email protected]>
2 participants
Summary
This PR prevents a hard crash when microphone stream initialization fails (for example, when Windows microphone privacy blocks access).
What changed
src-tauri/src/audio_toolkit/audio/recorder.rsAudioRecorder::open(expect/unwrap/panic) with explicit error propagation.open()only succeeds after worker initialization succeeds.src-tauri/src/actions.rsWhy
In release builds (
panic = "abort"), panic paths during recorder startup can terminate the process. This keeps startup failure as a normal error path instead.Refs #436