Files
openhuman/app/src-tauri
08d9fd2d4d fix(voice): recover buffered hotkey events after select! race (#527) (#545)
* fix(voice): return receiver count from publish_transcription

publish_transcription now returns the number of active TRANSCRIPTION_BUS
subscribers that received the message. When no receivers are connected
(e.g. Socket.IO bridge not yet subscribed), the function logs a warning
instead of silently discarding the broadcast.

This makes it possible to diagnose "transcription produced but never
delivered" scenarios from logs alone.

Closes #527 (partial)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

* fix(voice): recover buffered hotkey events after select! race

On warm CPAL init (second+ recording), audio_capture::start_recording()
completes fast enough that the pending_ready branch and the hotkey_rx
branch are both ready simultaneously inside tokio::select!. select!
picks one pseudo-randomly — when it picks pending_ready, the Released
event sits unprocessed in hotkey_rx. The recording is stored as "live"
with no deferred stop, then the next loop iteration processes the
buffered Released and stops the recording almost immediately, producing
a near-zero-length clip that the duration gate silently drops.

Fix: after pending_ready resolves, call hotkey_rx.try_recv() to check
for a buffered stop event that lost the race. If found, apply the
deferred stop mechanism (MIN_RECORDING_AFTER_SETUP = 1500ms) instead
of treating the recording as live.

Also adds pipeline_id (UUID prefix) to all process_recording_bg log
lines for end-to-end correlation, and labels each pipeline stage
(stop_recording, gate_duration, gate_silence, transcribe, deliver)
so dropped recordings are diagnosable from logs.

Closes #527

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-13 14:07:28 -07:00
..
2026-03-29 10:30:18 -07:00
2026-03-29 10:30:18 -07:00
2026-03-29 10:30:18 -07:00
2026-04-13 13:27:38 +00:00
2026-04-13 13:27:38 +00:00