fix(gateway): Deepgram defaults (unset language, Nova-only detection, Aura default voice); default fillers

[dittops]

Problem

On bud-dev (WaaV 0.1.7), every session of a voice agent with no language set failed with:

The upstream voice provider failed. The gateway said: Failed to start voice manager: STT error: Connection failed: Connection channel closed

The log shows Deepgram refused the handshake: Failed to connect to Deepgram: HTTP error: 400 Bad Request for

wss://api.deepgram.com/v1/listen?model=base&language=multi&...

The agent had no language and neither did its STT deployment (deepgram, model base). Yet WaaV sent language=multi, Deepgram's code-switching token, which only Nova-3 and Nova-2 accept.

Cause

map_language("") resolves an empty string to CanonicalLanguage::Auto, and a vendor that can detect the language gets its auto token. For Deepgram that token is multi, regardless of the model. So "nothing chosen" became "detect", and any Deepgram deployment whose model isn't Nova-3 or Nova-2 failed the handshake.

Fix

• An unset language is left out wherever the vendor can detect (core/lang::map_language), and the vendor's own default applies. This matches the rule the Deepgram URL builder already states: send only what the caller chose. Vendors that can't detect behave as before.
• Deepgram detects only on the models that can: nova-3, nova-3-general, nova-2 and nova-2-general. An explicit auto on any other model is left out with a warning (which /ws surfaces as a config_warning) instead of a 400.

Named languages are unchanged.

Second fix, found on retest: Aura family deployment with no voice

With the language fix live on bud-dev, the same agent got past STT, and then every sentence failed:

TTS error: deepgram rejected the request (400 Bad Request): Invalid 'model' value of 'aura-2'.

The TTS deployment is published under the family name aura-2, and the agent keeps the vendor-default voice. With nothing naming a voice, the family went out as Deepgram's model, which Deepgram never accepts for a family. A bare family (aura-2, aura) with no voice now resolves to Deepgram's default voice for that family: aura-2-thalia-en or aura-asteria-en. A chosen voice, and a deployment published under a full voice id, are unchanged.

Default filler script

AgentFillers::default() is now "Hmm...", "One moment.", "Still checking...", matching budapp's new DEFAULT_FILLER_MESSAGES (BudEcosystem/bud-runtime#3126). budapp always publishes the full fillers block, so this default only applies to a projection that lacks one. bud-auth/tests/fixtures/voice_agent_entry.json is budapp's regenerated copy, byte for byte.

Testing

cd gateway
cargo test --lib -- core::lang handlers::ws handlers::endpoint_settings core::stt core::tts handlers::openai_realtime core::agent   # 5003 passed
cargo +1.99.0 clippy --all-targets --features dag-routing,turn-ensemble,noise-filter,openapi -- -D warnings                        # clean
cargo +1.99.0 fmt --all --check && cargo fmt --all --check                                                                         # clean on 1.99 and 1.96

New tests:

• an_unset_language_is_left_out_not_sent_as_detection
• deepgram_detects_only_on_the_models_that_can
• The live case, deepgram + base + empty language, in p2_stt_auto_becomes_provider_default_or_native_token.
• a_family_with_no_voice_speaks_in_its_default_voice.
• bud-auth fixture test: asserts the default filler script (cd bud-auth && cargo test: 202 passed).

Mutation checks: removing either part of the language fix, or the family default, fails its tests.

🤖 Generated with Claude Code