feat(assemblyai): warn when audio stops flowing to the WebSocket#5478
Closed
gsharp-aai wants to merge 1 commit intolivekit:mainfrom
Closed
feat(assemblyai): warn when audio stops flowing to the WebSocket#5478gsharp-aai wants to merge 1 commit intolivekit:mainfrom
gsharp-aai wants to merge 1 commit intolivekit:mainfrom
Conversation
When a session appears wedged, a recv-side silence warning alone can't distinguish "AssemblyAI is stalled" from "the plugin stopped receiving audio from upstream and is correctly silent." This adds a symmetric send-side warning: if no audio frames have been written to the WebSocket for 15s+ while the recv loop is also silent, emit a warning with the elapsed idle time and session id, re-emitted every 15s while the drought continues. The two absence-of-activity signals together make the diagnosis unambiguous from logs alone, without external instrumentation.
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
Complementary to #5476 (recv-side silence warning).
#5476 warns when AssemblyAI sends no messages for 15s+. That's half the diagnostic picture — it can't distinguish "AssemblyAI is stalled" from "the plugin stopped receiving audio from upstream and is correctly silent." When a session appears wedged, both interpretations are on the table and the current logs can't separate them.
This PR adds the symmetric send-side warning: if no audio frames have been written to the WebSocket for 15s+ while the recv loop is also silent, emit
AssemblyAI no audio frames sent for Ns session=<id>, re-emitted every 15s while the drought continues.Together, the two absence-of-activity signals answer the question by elimination:
Implementation
self._last_frame_sent_at: float | None = None, set on every successfulws.send_bytes(...)insend_task.recv_task, tracksconsecutive_timeoutsin 5s ticks (matches the cadence feat(assemblyai): log connection lifecycle, silence, and session correlators #5476 introduces on the recv side). Every 3rd tick (15s), checktime.time() - _last_frame_sent_atand warn if it exceeds 15s.time.time()assignment per frame._last_frame_sent_at is not Noneso the warning doesn't fire during the initial connect window before any audio has been sent.Impact
warningonly, and only when the anomaly is real.Relationship to #5476
This PR is self-contained and doesn't depend on #5476 being merged first — it introduces its own
consecutive_timeoutscounter inrecv_task. If #5476 lands first, the counter line in this PR becomes a conflict trivially resolvable by keeping the existing one.Test plan
make format lint type-checkpassinput_chwhile keeping WS open): send-stopped warning fires at 15s, 30s, 45s