Conversation
…Away An immediate restart on goAway cut the reply being spoken; on gemini-3.8-live the resumed session then never answered again. The server's timeLeft is the outer bound for waiting out the current generation.
🦋 Changeset detectedLatest commit: 4c964e0 The changes in this PR will be included in the next version bump. This PR includes changesets to release 39 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
![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.
…goAway restart A finished generation stays assigned to currentGeneration with only _done set, so the idle check waited until the deadline after the first turn instead of restarting between turns. Match the completion state onReceiveMessage uses.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
Besides a completed generation, require no pending reply request, no blocking tool call awaiting its result and no manual user activity before reconnecting. Automatic activity detection gives the client no signal for an utterance in progress; the poll interval bounds that window.
| this.sessionShouldClose.set(); | ||
| return; | ||
| } | ||
| setTimeout(restartWhenIdle, GO_AWAY_IDLE_POLL_MS); |
Member
There was a problem hiding this comment.
If a session config update (such as updateTools()) triggers a reconnect, this timer can fire against the replacement connection. Could we capture the active session when handling goAway and return early if it has changed when the timer fires?
| (!this.currentGeneration || this.currentGeneration._done) && | ||
| !(this.pendingGenerationFut && !this.pendingGenerationFut.done) && | ||
| !this.shouldBlockRealtimeInputForPendingTools() && | ||
| !this.inUserActivity; |
Member
There was a problem hiding this comment.
After sending a blocking tool result, we clear the pending tool ID, but Gemini’s tool reply may not have started yet. Could we keep the turn busy during that wait?
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.
What
handleGoAwaysetsessionShouldCloseimmediately, so the session restarted while a generation was in flight. Observed ongemini-3.8-live(agents-js 1.9.0): agoAwaywithtimeLeft: "300s"arrived about a second into a session, the restart cut the opening reply mid-sentence, and the resumed session never produced another generation (onlyserverContent.interrupted: truein response to later client content).This waits until no generation is in flight before restarting, polling every 250 ms, and always restarts at
timeLeft - 10sso a generation that never completes cannot outlive the connection. Python's_handle_go_awayhas the same immediate restart (and the sameTODO: this isn't a seamless reconnection just yet); happy to port this there too if wanted.Related observation (not changed here)
With a forced mid-session restart on
gemini-3.8-live(anupdateTools()call between turns, which reconnects with the resumption handle), the model lost the chat context that was prefilled viaclientContentin 2 of 3 runs ("I do not have memory of previous sessions"), while the same restart with the resumption handle dropped (fresh connection + the plugin's own history prefill) kept it in 3 of 3. That suggests session resumption on 3.8 does not restore prefilledclientContent; I have not touched resumption here but can open a follow-up making it opt-out if that matches your reading.How verified
pnpm vitest run plugins/google/src/realtime/realtime_api.test.ts(11 passed, new case for the duration parser).pnpm exec prettier --writeon the two files; eslint reports only the three pre-existingno-explicit-anywarnings.Includes a patch changeset for
@livekit/agents-plugin-google.