[Rehansanjay]

Addresses the first half of #7867.

The bug

A response that finishes writes each message's accumulated transcript into its mirror item, in _handle_response_done:

for item_id, item_generation in self._current_generation.messages.items():
    if (remote_item := self._remote_chat_ctx.get(item_id)) and isinstance(
        remote_item.item, llm.ChatMessage
    ):
        remote_item.item.content.append(item_generation.audio_transcript)

A connection that drops mid-reply never delivers that event. The assistant item the response created is in the mirror, but with empty content, and _reconnect replays

chat_ctx = self.chat_ctx.copy(..., exclude_empty_message=True, ...)

so the item is dropped. The replayed conversation ends on the user's request with nothing answering it, and the model answers that request again on the next turn. What the caller hears is the agent stopping mid-sentence and then replying to the question before last.

The reporter saw it recur for the life of a call: on google/gemini-3.8-live through LiveKit Inference, server_error roughly 15 minutes after each (re)connection — errors at 18.0, 33.4 and 48.8 minutes in one 65-minute session — because Gemini Live caps audio sessions at 15 minutes while DEFAULT_MAX_SESSION_DURATION recycles at 20. A routine recycle is clean, since it waits for the current generation to finish; only the error path loses the reply.

The fix

Flush the transcripts the current generation has accumulated into the mirror before taking the snapshot that gets replayed. That keeps what was already said as a truncated assistant turn, which is what an interruption produces anyway — _handle_response_done runs on a cancelled response too, so this makes the dropped-connection path behave like every other way a reply can end early.

Each transcript is cleared once written. _reconnect restores old_chat_ctx if its sends fail and is then retried, and the transcript is still on the generation at that point, so without clearing a retry would append the same text twice.

Nothing else in the reconnect path moves: _close_current_generation still runs where it did, after the replay events are sent, so the generation's channels and futures are torn down in the same order.

Tests

tests/test_openai_realtime_reconnect_replay.py, three cases built on the RealtimeSession.__new__ harness the existing chat-context tests use, each asserting against exactly the copy _reconnect replays:

• what the agent already said survives the replay
• a retried reconnection does not duplicate it
• a reply that dropped before any transcript does not add an empty assistant turn

Verified by mutation — with the flush returning early and everything else unchanged:

E  AssertionError: assert ['item_55e1afc6c3e8'] == ['item_55e1af...4058210e3085']
E    Right contains one more item: 'item_4058210e3085'
E  AssertionError: assert ['What is the...l of France?'] == ['The capital...France is Pa']

The assistant turn disappears from the replay and the conversation ends on the user's question — the reported symptom.

Not in this PR

The issue's second half: DEFAULT_MAX_SESSION_DURATION is 20 minutes for every provider, while Gemini Live caps audio sessions at 15 without context-window compression, so the limit surfaces as a provider error rather than a clean recycle. A shorter default for google/ models, or handling Google's GoAway with session resumption, are both defaults-and-policy calls rather than a bug fix — happy to send whichever you'd prefer.

[devin-ai-integration]

Devin Review found 1 potential issue.

1 flag not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)

[devin-ai-integration]

🟡 Replayed reply includes unspoken words

If transcript deltas precede audio at disconnect, _flush_generation_transcripts replays words the caller never heard. The next reply treats those words as already spoken.

Learn more

Transcript deltas and audio deltas arrive in separate server events; audio handling buffers each independently. On a dropped connection, the last received transcript can describe audio that never arrived or played. The replay serializes that transcript as an assistant answer, although realtime playout has no corresponding audio to forward. The reverse ordering also leaves spoken audio with an empty transcript, which this flush skips entirely.

Example: The server sends transcript The code is 1234 but only sends audio for The code is before disconnecting. The replay claims the assistant already said 1234, so a follow-up can proceed without giving the caller the code.

Recommended fix: Reconcile the replayed transcript with audio actually forwarded by the voice generation task, or preserve only the portion whose audio was confirmed delivered. Account for audio received before any transcript as well; do not treat the full accumulated transcript as proof of speech.

---

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

[Rehansanjay]

This flag is right about the mechanism, and I had a counter-argument that does not survive reading truncate.

I was going to say the flush is consistent with how an interruption already behaves. It isn't. An interruption sends conversation.item.truncate with audio_end_ms, so the server is told exactly how much was heard, and the item is deleted outright when nothing was played. That path knows the played length. A dropped socket cannot send anything, so by the time _reconnect runs there is no played-length information in the session at all — only the transcript the server had already delivered. So the flush writes everything generated, which can exceed everything heard by whatever audio was buffered and unplayed when the connection died.

Why I would still land it, and I'd rather state the trade than have a reviewer find it:

Without the flush the replayed conversation ends on the user's request with nothing answering it, and the measured consequence is the model answering that request again on the next turn — the caller hears the agent stop mid-sentence and then reply to the question before last, recurring every ~15 minutes for the life of the call on google/gemini-3.8-live. With the flush, the turn is present but its tail may claim a few hundred milliseconds to a couple of seconds the caller did not hear. One is a wrong answer to the wrong question; the other is a slightly over-long record of the right one.

The principled version needs the played length reconciled from the voice generation task, which is the only place that knows it, and getting it into the mirror before the replay is sent on a socket that is already gone. That is a bigger change than this, and the ordering is the hard part, not the arithmetic.

Happy to go either way: land this as the smaller improvement with the limitation documented, or close it and open an issue for the reconciled version. I don't think leaving the turn out entirely is the better default, but it's your call.