fix(voice_ui): stop wake-word listener when a recording starts #17

Merged

thabeta merged 2 commits from development_listen_stop_on_record into development

2026-04-23 09:16:43 +00:00

salmaelsoly commented

2026-04-23 06:04:24 +00:00

Member

Summary

When a client sent Start while in wake-word listen mode, only is_recording was flipped to true. The is_listening flag stayed true and listen_processor's VAD buffer kept its stale contents. The existing !recording guard on the wake-word branch prevented most user-visible impact, but the state inconsistency and the unreset buffer were real bugs (e.g. stale data surviving into the next Listen).

This PR adds two lines to the Start arm of handle_socket so that Start now cleans up listen state exactly the way Stop already does.

Closes #13

Changes

Single-file, crates/hero_voice_ui/src/ws.rs, inside the ClientMessage::Start arm:

Set *is_listening.lock().await = false so the flag stops being stale until the next Stop.
Call listen_processor.lock().await.reset() so wake-word detection starts clean on re-entry.
No change to the client wire protocol. No new messages, no new fields.
Lock-acquisition order matches the rest of the file; no lock is held across an await on another lock.

Test Results

cargo test --workspace — 18 passed, 0 failed.
cargo clippy -p hero_voice_ui --all-targets -- -D warnings — clean.

No unit test is added. The bug is a state-machine flag inside an async WebSocket handler whose surrounding context (axum::WebSocket, mpsc channels, LocalTranscriber) is not currently factored for unit testing; extracting a helper purely to test two flag writes would add more indirection than it removes. Manual verification is the accepted path (see the spec comment on the issue).

## Summary When a client sent `Start` while in wake-word listen mode, only `is_recording` was flipped to `true`. The `is_listening` flag stayed `true` and `listen_processor`'s VAD buffer kept its stale contents. The existing `!recording` guard on the wake-word branch prevented most user-visible impact, but the state inconsistency and the unreset buffer were real bugs (e.g. stale data surviving into the next `Listen`). This PR adds two lines to the `Start` arm of `handle_socket` so that `Start` now cleans up listen state exactly the way `Stop` already does. ## Related Issue Closes https://forge.ourworld.tf/lhumina_code/hero_voice/issues/13 ## Changes Single-file, `crates/hero_voice_ui/src/ws.rs`, inside the `ClientMessage::Start` arm: - Set `*is_listening.lock().await = false` so the flag stops being stale until the next `Stop`. - Call `listen_processor.lock().await.reset()` so wake-word detection starts clean on re-entry. - No change to the client wire protocol. No new messages, no new fields. - Lock-acquisition order matches the rest of the file; no lock is held across an await on another lock. ## Test Results - `cargo test --workspace` — 18 passed, 0 failed. - `cargo clippy -p hero_voice_ui --all-targets -- -D warnings` — clean. No unit test is added. The bug is a state-machine flag inside an async WebSocket handler whose surrounding context (`axum::WebSocket`, `mpsc` channels, `LocalTranscriber`) is not currently factored for unit testing; extracting a helper purely to test two flag writes would add more indirection than it removes. Manual verification is the accepted path (see the spec comment on the issue).

salmaelsoly added 1 commit

2026-04-23 06:04:24 +00:00