fix(google): don't start a generation from audio trailing a tool call

[Darshak03]

A tool call ends the turn and _handle_tool_calls finalizes the generation, but the server can keep streaming model_turn audio that belongs to it. _is_new_generation() returned True for any model_turn, so a single trailing frame opened a second generation for a turn that was already over.

From a live call:

input_transcription(finished, "My Monster Jam device is not working.")
  -> new generation started: GR_e618ac79ab58
  ... model_turn audio + output_transcription stream the full reply ...
tool_call  Get_Products
  -> generation done: GR_e618ac79ab58
     output_text='I completely understand how frustrating that must be.
                  Please give me just a moment while I pull up your details.'
output_transcription(finished=True)          # no .text, correctly ignored
model_turn(inline_data=audio/pcm)            # trailing frame from the finished turn
  -> new generation started: GR_ffb4da1884e7
generation_complete=True
turn_complete=True, usage_metadata(total_token_count=1230)
  -> generation done: GR_ffb4da1884e7  output_text=''   (lived 0.5 ms)

Three consequences:

1. The spurious generation interrupts the one still playing, so the assistant message is committed as content: ['I completely'], interrupted: True while the plugin holds the full sentence in output_text.
2. _SegmentSynchronizerImpl.playback_finished called before text/audio input is done — the synchronizer cut off mid-turn.
3. usage_metadata arrives with turn_complete, by which point _current_generation is the empty one, so the turn's tokens are recorded against a generation that produced nothing.

Fix: remember that a tool call ended the turn, and ignore model_turn until the turn really ends. The flag is cleared wherever a new turn legitimately begins — _start_new_generation, turn_complete, and generate_reply, the last so a reply requested right after a tool call is not suppressed.

The trailing content itself was already handled: push_text guards on text_ch.closed and the audio branch guards on audio_ch.closed, both dropping with a warning. The only damage came from _start_new_generation() being called, so suppressing that is sufficient and nothing else changes.

_is_new_generation() already carried a comment about this class of event — it excludes empty transcriptions and generation_complete for the same reason — model_turn was the gap.

Tests: three, covering the trailing frame, that the next real turn still opens a generation, and that generate_reply after a tool call is not suppressed. All three fail on main.

Fixes #7195

[devin-ai-integration]

Note

This report is out of date. Scroll down for Devin Review's latest report on this PR.

Devin Review found 2 new potential issues.

[devin-ai-integration]

🟡 Requested replies remain suppressed

When generate_reply follows an unanswered tool call, its request reaches Gemini while _turn_ended_by_tool_call remains set. The model response cannot open a generation, so the returned future times out.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[Darshak03]

I do not think this one should be changed, because the fix for it reopens the finding that was just resolved above.

The two are in direct tension. The earlier comment was that clearing before the request reaches Gemini lets trailing audio resolve the pending reply with stale content. Clearing when the request does reach the socket narrows that window but does not close it — audio from the finished turn can still arrive after our send. So adding a wrapper to clear on send trades a user-visible wrong reply for a timeout in a case that is already blocked for another reason.

On that case: an unanswered tool call blocks the model by design. From #6785, which fixed exactly this: "A realtime model holds each call it emitted open until it is answered, so Gemini Live stopped responding and later generate_reply() calls produced no generation (#6569)." So with a call outstanding, generate_reply yields no generation at the protocol level, whatever this flag does. The timeout is #6569's, not this flag's.

It also needs turn_complete to be missing. In the call this PR is based on, the tool call and turn_complete land within the same millisecond, and turn_complete clears the flag — so the window where the flag is still set and a reply is requested is about that wide, and any tool doing real work is far outside it.

Between the two, suppression that lasts slightly too long in a case the protocol already blocks seems better than suppression that ends slightly too early in a case that silently attaches the wrong audio to the caller's reply. The model that ends such a turn without a turn_complete is covered by the tool-response clear, so it cannot be suppressed indefinitely either.