Conversation
The /voice status command only checked for 'local', 'groq', and 'openai' providers. Any other valid provider (local_command, mistral, xai, elevenlabs, or custom command providers) fell through to the generic MISSING message — even when transcription worked perfectly. - Import _has_any_command_stt_provider (already defined, never imported) - Add elif branches for local_command, mistral, xai, elevenlabs - Add generic catch-all via _has_any_command_stt_provider() for arbitrary custom command providers
alt-glitch
added
type/bug
zehuaw1
marked this pull request as ready for review
June 8, 2026 01:22
Closed
teknium1
reviewed
Jul 14, 2026
teknium1
left a comment
teknium1
left a comment
Collaborator
There was a problem hiding this comment.
Thanks for addressing a real /voice status gap: current main only reports local, groq, and openai as OK in tools/voice_mode.py:1160-1171, while tools/transcription_tools.py:776-828 and :1666-1695 support additional native providers.
Problems
- The new
_has_any_command_stt_provider(stt_config)branch is not tied to the selected provider. That helper returns true for any configured command provider (tools/transcription_tools.py:355-361), so an unrelated command entry can make an unknown or plugin-selected provider appear OK. - The current dispatcher also supports registered plugin STT providers (
tools/transcription_tools.py:1713-1737), which the proposed status branches do not cover. tests/tools/test_voice_mode.py:444-499has no coverage for these added provider-status paths.
Suggested changes
- Resolve the selected command provider specifically, and add tests covering selected versus unrelated command providers plus the plugin path.
Automated hermes-sweeper review.
teknium1
added
sweeper:risk-compatibility
PR review feedback: - Replace _has_any_command_stt_provider() with selected-provider check via _resolve_command_stt_provider_config() - Add _check_plugin_stt_provider() for plugin-registered backends - Add tests: selected command, unrelated command (should NOT pass), and plugin provider path
Collaborator
|
Merged into main via consolidated salvage PR #73510 (merge Your contribution is credited to you in git history. Thank you! Closing this PR as merged-via-salvage. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
/voice statusonly checks forlocal,groq, andopenaiproviders. Any other valid provider —local_command,mistral,xai,elevenlabs, or a custom command provider — falls through to the generic MISSING message, even when transcription works perfectly.The function
_has_any_command_stt_provider()was already defined intranscription_tools.pybut never imported invoice_mode.py.Fix
tools/voice_mode.py— 11 insertions, 1 deletion:_has_any_command_stt_providerfromtranscription_tools.pyelifbranches forlocal_command,mistral,xai,elevenlabs_has_any_command_stt_provider()for arbitrary custom command providersRisk
None. Existing providers (local, groq, openai) behave identically. Code change is purely additive — the new elif branches sit between the existing ones and the else clause.
Related: #41659