fix(voice): respect allow_interruptions=False with server-side turn detection - #6638
Closed
biztex wants to merge 5 commits into
Closed
fix(voice): respect allow_interruptions=False with server-side turn detection#6638biztex wants to merge 5 commits into
biztex wants to merge 5 commits into
Conversation
…etection RealtimeModel sessions using server-side turn detection forced interruptions on: the activity raised ValueError when allow_interruptions=False, say() and generate_reply() silently overrode an explicit False, and every input_speech_started event unconditionally sent response.cancel - cutting the agent off on any speech overlap. Manual/button-style turn-taking setups that configure the provider with interrupt_response=False could not opt out without forking. The coupling was defensive, not fundamental (interrupt() would have raised on a non-interruptable speech). Respect the setting instead: construction logs a warning reminding that the provider must be configured to match (otherwise the server still cancels its side), input_speech_started skips the local interrupt when interruptions are disallowed, and say()/generate_reply() no longer override an explicit False. Fixes livekit#6635
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
interruptibility is a per-speech property: with the say()/generate_reply() overrides gone, an explicitly protected speech could exist while the session default allows interruptions, and input_speech_started then raised (and logged) a spurious RuntimeError from interrupt(). The symmetric case - an explicitly interruptible speech under a protective session default - was never interrupted locally. The session-wide default now only decides when no speech is playing.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
…rupt() with the overrides gone a protected handle can sit in the speech queue while an interruptible one plays; SpeechHandle.interrupt() then raised mid-loop, aborting the rest of the interruption sequence (remaining queued speeches, rt_session.interrupt(), the done-callbacks wiring the returned future) and logging a misleading internal error. Queued handles are now filtered the same way background speeches already are.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
the streaming realtime response belongs to the newest queued generation, so sending response.cancel while a protected reply sits in the queue truncated exactly the speech that was just preserved. The cancel is now skipped in that case (force still cancels); interrupted handles stop locally either way and truncate their own chat-context item when playout ends partial, which is independent of the cancel.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
the previous proxy - any protected handle in the queue - suppressed response.cancel in the common flow where the streaming response belongs to the playing speech and the protected handle is a not-yet-started say(), leaving the provider generating a reply nobody hears. The activity now tracks the handle that owns the in-flight realtime generation, and the cancel is skipped only when that handle disallows interruptions and is still live.
Contributor
|
closing in favor of #6642 |
This was referenced Jul 31, 2026
Contributor
Author
|
Makes sense — #6642 solves #6635 at the right level; reclassifying Two things the review here turned up are independent of that and still reproduce on main (a pipeline agent with |
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
2 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.
Fixes #6635
Problem
RealtimeModel sessions with server-side turn detection forced interruptions on, in three places:
AgentActivityraised aValueErrorwhenallow_interruptions=False;say()andgenerate_reply()silently overrode an explicitFalseback to the default; and everyinput_speech_startedevent unconditionally calledinterrupt(), sendingresponse.cancelto the provider. Any overlap between agent and user speech cut the agent off — even in manual/button-style turn-taking setups that explicitly configure the provider withinterrupt_response=False(the issue reporter was facing a fork to escape this).Why the coupling existed — and why it can go
The comment above the unconditional interrupt explains it:
interrupt()raises whenallow_interruptionsisFalse, andinput_speech_startedonly fires with server-side turn detection — so the constraint existed to avoid that raise, not because the combination is meaningless. Guarding the call sites removes the need for the constraint.Change
ValueErrorbecomes a warning that reminds the user the provider must be configured to match (e.g.interrupt_response=Falsein the OpenAIturn_detectionsettings) — otherwise the server still cancels the in-progress response on its side, which the client cannot prevent._on_input_speech_started: skips the localinterrupt()/response.cancelwhen interruptions are disallowed (user-state bookkeeping unchanged).say()/generate_reply(): an explicitallow_interruptions=Falseis respected instead of silently overridden with a warning.Default behavior (interruptions allowed) is byte-identical.
Tests
New hermetic
tests/test_realtime_allow_interruptions.pyon the fake realtime model: construction succeeds with the warning (and stays silent when interruptions are allowed), andinput_speech_startedcallsinterrupt()when allowed / never when disallowed. Full unit suite passes unchanged.