Uh oh!
There was an error while loading. Please reload this page.
feat(live): use RunConfig.session_resumption.handle when opening a live session - #6770
Merged
Merged
Conversation
Streaming tools and non-blocking tools run as background asyncio tasks that nothing owns: only an explicit `stop_streaming` call ever cancelled one. When a live agent run ended for any other reason -- a handoff to another agent, `task_completed`, the model closing the connection, the caller walking away -- its tools kept running, feeding function responses into a live request queue that by then belonged to another agent, which never made those calls, or to nobody at all. The tasks were never awaited either, so a failure in one surfaced only as a stray asyncio warning. `BaseLlmFlow.run_live` now cancels the background tools its run started before it returns, and at a handoff it cancels them before the sub agent takes over the live request queue rather than when the enclosing run eventually finishes. Cancellation is best effort: a task that ignores it is logged instead of stalling the handoff or the caller's teardown. Stopped tools also give up their registry entry. `_send_to_model` copies every live request into each registered stream, so a stream left behind by a tool that is no longer reading kept growing for the rest of the session, one entry per audio chunk the user spoke. Co-authored-by: Liang Wu <wuliang@google.com> PiperOrigin-RevId: 964915958
…ve session A caller that resumes an earlier live session by passing a handle in `RunConfig.session_resumption.handle` only got that handle onto the wire. The basic request processor forwards it to `LiveConnectConfig`, but every other part of the run keys off `InvocationContext.live_session_resumption_handle`, which was populated exclusively from a server-issued `session_resumption_update`. The run therefore behaved as if the session were new: it replayed the whole conversation through `send_history()` even though the server already held that state, declared that history as `initial_history_in_client_content`, left `transparent` unset on the Vertex AI backend, and raised instead of reconnecting when the socket dropped before the server issued its first handle. Seed `InvocationContext.live_session_resumption_handle` in `BaseLlmFlow.run_live` from the handle request assembly has already put on `llm_request.live_connect_config.session_resumption`, before the connect loop, so the first connection is treated as a resumption in the same way as any mid-session reconnect. Reading the assembled request rather than the `RunConfig` keeps the seed on the same object the reconnect path goes on to write, and honors a handle set by any request processor rather than only one set through `RunConfig`. Agent transfer is unaffected because it already clears both the invocation handle and the deep-copied run config handle, so a child agent still starts a fresh live session. Co-authored-by: Liang Wu <wuliang@google.com> PiperOrigin-RevId: 966066295
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Backport of commit eac32c3 (
feat(live): use RunConfig.session_resumption.handle when opening a live session, PiperOrigin-RevId: 966066295) frommaintov1.A caller that resumes an earlier live session by passing a handle in
RunConfig.session_resumption.handleonly got that handle onto the wire. The basic request processor forwards it toLiveConnectConfig, but every other part of the run keys offInvocationContext.live_session_resumption_handle, which was populated exclusively from a server-issuedsession_resumption_update. The run therefore behaved as if the session were new: it replayed the whole conversation throughsend_history()even though the server already held that state, declared that history asinitial_history_in_client_content, lefttransparentunset on the Vertex AI backend, and raised instead of reconnecting when the socket dropped before the server issued its first handle.Seed
InvocationContext.live_session_resumption_handleinBaseLlmFlow.run_livefrom the handle request assembly has already put onllm_request.live_connect_config.session_resumption, before the connect loop, so the first connection is treated as a resumption in the same way as any mid-session reconnect. Reading the assembled request rather than theRunConfigkeeps the seed on the same object the reconnect path goes on to write, and honors a handle set by any request processor rather than only one set throughRunConfig. Agent transfer is unaffected because it already clears both the invocation handle and the deep-copied run config handle, so a child agent still starts a fresh live session.Testing Plan
pytest tests/unittests/flows/llm_flows/test_base_llm_flow.py(56 passed)pyinkandisortclean.