False interruption keeps stale started_speaking_at for next user turn

[peaks-agent]

Bug Description

After a confirmed false interruption resumes agent speech, LiveKit Agents keeps the discarded user recognition turn alive. The next real user transcript inherits the false turn's original speech-start anchor, so ChatMessage.metrics.started_speaking_at can predate the actual utterance and be ordered before agent speech that really occurred first.

This reproduces on livekit-agents==1.7.1. The ordering guard from #6093 / #6098 does not cover it because the resulting user metrics remain internally ordered (stopped_speaking_at >= started_speaking_at); the start anchor is stale but not mathematically impossible.

Deterministic timeline

Observed production timeline, UTC:

1. 19:20:06.481 — VAD opens a user turn; no STT is committed.
2. 19:20:10.114 — LiveKit confirms a false interruption and resumes the paused agent speech.
3. 19:20:18.632 — the user actually begins the later utterance.
4. The committed user ChatMessage reports started_speaking_at = 19:20:06.481, 12.151 seconds before the real utterance.

This incorrectly places the user line before the resumed agent response in timestamp-sorted transcripts.

Deterministic code-path reproduction

On 1.7.1:

1. Create an AgentActivity with resume_false_interruption=True, paused speech whose agent_state == "speaking", and an active AudioRecognition turn with _speech_start_time set by VAD but no committed transcript.
2. Trigger _start_false_interruption_timer(0) and let _on_false_interruption(resumed=True) complete.
3. Observe that agent speech starts/resumes, but AudioRecognition._clear_user_turn() is never called.
4. Emit a later real user utterance and commit its transcript.
5. The resulting ChatMessage.metrics.started_speaking_at is the step-1 VAD timestamp, not the later utterance's start.

A deterministic spy around step 2 shows the current resume path lacks recognition cleanup. The local patch changes the event order to:

clear_user_turn -> start_agent_speech -> audio_resume

Expected Behavior

Once a false interruption is confirmed and paused agent audio will resume, the uncommitted recognition turn should be discarded before agent speech resumes. Its logical-turn/span anchor, speech timing anchors, buffered transcript, and related turn state must not survive into the next real user utterance.

Actual Behavior

_on_false_interruption resumes the agent state/audio without clearing the active recognition turn. The next committed user message can inherit the abandoned turn's started_speaking_at.

Proposed Solution

Call the recognition turn's existing full clear/reset path before _on_start_of_agent_speech and audio resume when agent_false_interruption(resumed=True) is accepted. Resetting only _speech_start_time would leave other discarded-turn state behind.

PeakSend has a version- and checksum-pinned 1.7.1 patch implementing and build-verifying this ordering:

• Patch PR: https://github.com/PeakSend-AI/peaksend/pull/561
• Production RCA: https://github.com/PeakSend-AI/peaksend/issues/559

Those links are in a private repository, but the complete reproduction timeline and patch boundary are included above.

Package Versions

livekit-agents==1.7.1

The original incident was observed on 1.6.9 and confirmed against the 1.7.1 source.

[dorukdumlu]

Confirmed on current main, and the root cause sits one step deeper than the resume path missing a cleanup call: _ensure_user_turn_span returns a recording span as-is, and _user_turn_start is only written when it is None. Once the false turn's span survives the resume, the next real utterance silently reuses both, and _bounce_eou_task stamps the abandoned turn's start into started_speaking_at at commit. The #6093 guard can't catch it because the anchors stay internally consistent; they are just anchored to a dead turn.

Fix: #7101. It follows the ordering you proposed (discard before state restore and audio resume), with two deviations:

• the clear is skipped when the user is speaking at the moment the timer fires. Those anchors belong to a live utterance, and the timer can genuinely fire mid-speech: a below-min_duration VAD segment never reaches the timer reset in _interrupt_by_audio_activity.
• the discard keeps the live STT stream (reset_stt=False) instead of the full _clear_user_turn teardown. Recreating the provider stream on every false interruption is costly, and worse, it drops audio the provider is still decoding: if the barge-in was real after all (a VAD miss), that late final is the only thing left that can interrupt the resumed speech.

One behavior note: a final arriving after the resume now commits as a fresh turn without started_speaking_at, since the anchors are gone. Unknown seemed more honest than an anchor the system had already declared false.

[dorukdumlu]

A correction to my comment above: I hadn't seen #7066 and #7067 when I opened #7101, my mistake for missing the linked PRs. Since there are three attempts now, a comparison for whoever reviews this:

All three discard the abandoned turn on resume, so the reported bug is fixed by any of them. The differences are in what survives the discard.

#7067 calls the full _clear_user_turn() unconditionally. That recreates the STT pipeline (_update_stt(None) and back) on every false interruption, and it drops audio the provider is still decoding, which is the only thing left that can interrupt the resumed speech when the barge-in was real and VAD missed it.

#7066 splits by whether the end-of-turn decision ran: full clear for a decided-and-dropped turn, a lighter anchor release when no decision ever ran. The _open_user_turn centralization there is good hygiene whichever PR lands. Three things I'd flag: the decided-and-dropped branch still does the full STT teardown, and per that PR's own analysis the dropped backchannel is the common case, so the reconnect cost lands on the common path. The release can also fire while the user is mid-speech, through two windows: a below-min_duration VAD segment never resets the timer (and has no open eou task for the timeout to defer to), and in stt mode a premature STT END_OF_SPEECH clears _speaking while VAD is still mid-segment; in both, the release takes a live utterance's anchor and span with it. And since every path that appends a final to the transcript also starts the eou bounce, the undecided branch runs with an empty transcript in practice, so the preservation it buys is narrow.

#7101 keeps the STT pipeline in all branches (reset_stt=False on the existing clear) and skips the discard entirely while either STT or VAD still tracks live speech. The trade-off relative to #7066: no decided/undecided split, the release is uniform.

Happy to fold #7101's deltas into #7066 if that's the preferred base, the split and the deltas are not mutually exclusive.