[LUM-753] Add diagnostic logging to dictation recording lifecycle#24067
Conversation
… lifecycle - Log entry point of beginRecording() with origin, mode, and current state - Log speech recognizer availability details (nil vs unavailable) - Log permission status for both microphone and speech recognition - Log recognition task state when skipping due to active task - Track recording start timestamp and log elapsed time at every stop point - Detect and warn on micro-recordings (<1s) that indicate silent failures - Log recognition error details including NSError domain and code - Log empty final transcription as warning with elapsed time - Log audio engine failure with elapsed time Co-Authored-By: tkheyfets <timur@vellum.ai>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
|
Devin is archived and cannot be woken up. Please unarchive Devin if you want to continue using it. |
3 similar comments
|
Devin is archived and cannot be woken up. Please unarchive Devin if you want to continue using it. |
|
Devin is archived and cannot be woken up. Please unarchive Devin if you want to continue using it. |
|
Devin is archived and cannot be woken up. Please unarchive Devin if you want to continue using it. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| @@ -949,7 +969,7 @@ final class VoiceInputManager { | |||
| overlayWindow.dismiss() | |||
| } | |||
| awaitingDaemonResponse = false // reset for next recording | |||
There was a problem hiding this comment.
🚩 Pre-existing: awaitingDaemonResponse reset in stopRecording() after overlay check
At line 971, awaitingDaemonResponse is reset to false immediately after the overlay-dismiss check at line 968. In the dictation flow, handleFinalTranscription sets awaitingDaemonResponse = true (line 878), then the recognition callback calls stopRecording() which checks the flag (preserving the overlay) but then resets it. When handleDictationResponse later arrives (line 893-894), the flag is already false. This means any code that checks awaitingDaemonResponse between stopRecording() and handleDictationResponse will see false. This is pre-existing behavior unaffected by this PR, and the only consumer of the flag during that window appears to be another stopRecording() call (which would dismiss the overlay prematurely if triggered). Worth noting but not a regression.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep them coming! ℹ️ About Codex in GitHubCodex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback". |
|
provides extra logging for dictation |
tkheyfets
deleted the
devin/1775588602-LUM-753-dictation-diagnostic-logging
branch
1 participant
Summary
Adds comprehensive diagnostic logging to
VoiceInputManagerto help investigate dictation auto-stop issues on cloud-hosted assistants (LUM-753). Currently, when dictation fails to start or stops immediately, there is almost no logging — making it impossible to diagnose remotely. This PR instruments every early-return and failure path in the recording lifecycle.No behavioral changes — only logging additions:
beginRecording()with origin, mode, and current stateNSErrordomain + code on recognition errors for richer diagnosticsstopRecording()is called while already stopped (state inconsistency)Review & Testing Checklist for Human
os.Loggercalls,String(describing:)usage,CFAbsoluteTimeGetCurrent()arithmetic).VoiceInputcategory, and that they contain useful diagnostic info (origin, permissions, elapsed time).Notes
beginRecording()are the most likely culprits but are currently invisible without logs. This PR makes them visible so the next reproduction produces actionable diagnostics.DictationClient.swift.Link to Devin session: https://app.devin.ai/sessions/4d99242121f94fed84c1d80e873c569a
Requested by: @tkheyfets