We have an independent production reproduction in an inbound SIP call. Our build is pinned to @livekit/agents 1.5.3.
One interrupted speech handle remained current for approximately 293 seconds and was repeatedly targeted by subsequent interruptions. During that period, eight later LLM and TTS operations completed successfully, but there were no agent-speaking or playout events. Eight queued speech handles only closed as interrupted during shutdown.
The failure boundary logged:
SegmentSynchronizerImpl.onPlaybackStarted called after startFuture is set
Earlier interruptions in the same call recovered normally. No tool call or handoff was active at the failure boundary, and audio review confirms the agent channel was silent.
This appears to match issue #2065 and PR #2070. Does PR #2070 cover this ordinary-turn path, and is there a target release?
Any workarounds that people are using? This is impacting 3% of our calls.
@kyle_shechtman It should cover the ordinary-turn path. The wedge isn’t specific to how the speech handle was created it’s the second unguarded await on the generation future in AgentActivity.mainTask, which deadlocks the same way whether the reply came from a programmatic call or a normal turn. Only the trigger differs; the INTERRUPTED_GENERATION_TIMEOUT guard sits downstream of that distinction, so the ordinary-turn case falls out for free.
One thing worth re-anchoring: SegmentSynchronizerImpl.onPlaybackStarted called after startFuture is set is a logger.warn and early return in synchronizer.ts (agents-js/agents/src/voice/transcription/synchronizer.ts at main · livekit/agents-js · GitHub) it’s a downstream symptom of the ordering, not the point where you wedge. For alerting, _currentSpeech staying non-null with no agent_state transition to speaking is the reliable marker.
Until it merges, patching is the only real fix pnpm patch @livekit/agents@1.5.3 with the #2070 diff. A watchdog that force-interrupts once a handle has been current for more than a few seconds with no playout will bound the blast radius at 3% of calls, but it won’t clear the underlying await.
Is this a regression? Or has this always affected 3% of your calls, despite being on the latest version.