feat(azure): add STT cancellation recovery - #2009
Merged
Merged
Conversation
🦋 Changeset detectedLatest commit: 4f3b4cd The changes in this PR will be included in the next version bump. This PR includes changesets to release 37 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Co-authored-by: Cursor <cursoragent@cursor.com>
Cancel and finish the old Azure audio reader before closing its push stream so recovery cannot split frames across recognizers. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
toubatbrian
approved these changes
Jul 15, 2026
Merged
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
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.
Summary
Ports livekit/agents#6362 by adding the missing Azure streaming STT plugin infrastructure to agents-js and preserving the cancellation-error recovery behavior: Azure error cancellations wake the stream, surface an
APIConnectionError, and allow the base STT retry/fallback path to proceed instead of hanging.Source diff coverage
Coverage
livekit-plugins/livekit-plugins-azure/livekit/plugins/azure/stt.pyplugins/azure/src/stt.ts. The target repo had no Azure plugin/package, so this PR adds the Azure STT package infrastructure and ports the streaming STT behavior needed for the source fix, including_cancellationErrortracking, clearing it per recognition run, waking the stopped event from error cancellations, and raising a retryableAPIConnectionErrorwhen the stopped path observes the cancellation.tests/test_plugin_azure_stt.pyplugins/azure/src/stt.test.ts. The source unit tests are ported to Vitest and target the JS SDK cancellation event shape while preserving the same assertions: error cancellations unblock the run and non-error cancellations are ignored.Validation
pnpm test plugins/azurepnpm --filter @livekit/agents-plugin-azure lintpnpm --filter @livekit/agents-plugin-azure buildpnpm --filter @livekit/agents-plugin-azure api:checkpnpm buildpnpm lint(passes; existing warnings remain in unrelated packages)Notes
The source diff was 2 files and below the >20 files or >1000 lines planning POST threshold, so no port-plan POST was required.
Ported from livekit/agents#6362
Original PR description
If Azure STT hits an error cancellation (like a service timeout), the stream just goes silent.
_on_canceledonly logged a warning, and Azure doesn't reliably sendsession_stoppedafter that, so_runblocks on itsasyncio.waitforever. Audio keeps flowing into a dead recognizer and nothing raises, so retry and fallback never kick in.Now an error cancel records the details and sets the stopped event, so
_runwakes and raisesAPIConnectionError. The base retry loop and FallbackAdapter handle it from there.I kept it on the base retry path instead of adding retry inside the plugin like the earlier attempt (#5333). Happy to flip it if you'd rather.
Tests in
tests/test_plugin_azure_stt.pycover both cases.Fixes #5322
Cue voice E2E
4f3b4cd9496faff705094d1d56faaa6c927f5695.sid_84f8daeb8661.debug_message(kind=azure_recovery, phase=recovered) -> final user_input_transcribed(azure cancellation recovery verified) -> AS_SPEAKING -> AS_LISTENING. It resolved in 7.720 seconds only after assistant playout completed.recognizer_start(attempt=3); resolved in 2.001 seconds. The complete persisted event stream contains zero attempt-3 events.attempts=2,reconnect_count=1,max_active_readers=1,active_readers=1,dead_stream_writes=0,recovered_frames=8.AS_SPEAKINGat 12,284 ms;AS_LISTENINGat 14,288 ms. Worker logs also record the injected timeout, retryableAPIConnectionError, replacementSTART_OF_SPEECH, final transcript, and uninterrupted playout completion.ff695c0d88fdbe78d0cce2ea6225e827e0084b5d268bd06ec052702adbc1ee31.47fc40af0bf9c0326fb896143d6f5d04749d698800442eefb9f67f940f2fdbeb.events.jsonl: SHA-25685e569779ebd79079de3062464d958791804409b10a9e8654717db123aaef98a. Recoveryresult.json: SHA-256833b32dd58c18b55ba0c2b347c5042b0cb53ca33c726342ca224ee8279f5db1b.ServiceTimeoutcancellation. LiveKit Cloud transport plus production LiveKit Inference LLM/TTS were real; this was not a production Azure STT call.