fix: check every function response, not just the first, when resolving which agent to resume - #810
Open
prasanna8585 wants to merge 1 commit into
Conversation
…g which agent to resume Independent finding, not a response to review feedback. Found via a same-day sibling fix in google/adk-python (fix: check every function response, not just the first, when inferring which invocation to resume, commit 5449314) while auditing a routine commit batch -- adk-python's Runner._resolve_invocation_id had the identical gap in the Python port of this same resumption logic. findMatchingFunctionCall resolved which agent to resume after a tool/LRO boundary using only functionResponses[0].id from the last session event. A single event can carry responses answering calls from different agents at once -- for example two long-running operations from sibling sub-agents completing together and being resumed in one message. Resolving from only the first response silently attributed the rest to whichever agent's call happened to come first: that response would then be processed under a resumed agent's context it was never meant for, and the agent it actually answers would never be correctly resumed at all. Dynamically confirmed before fixing: a PoC with two sibling agents (agent_a, agent_b) each raising their own long-running call, resumed together in a single event, resolved to agent_a via determineAgentForResumption -- completely silent about agent_b's response belonging to a different agent entirely. Fix mirrors adk-python's exact fail-closed philosophy, adapted to this function's own return type (an Event, not a bare invocation id): every function response in the last event is now checked, and when the responses present resolve to calls authored by more than one distinct agent, the function throws rather than picking one -- determineAgentForResumption's only caller can resume a single agent, so an event answering calls from two different agents at once has no single correct answer to fail open with. Dynamically confirmed the fix closes the gap: reverted it in isolation, rebuilt, and reproduced the exact silent-misattribution PoC before restoring and confirming it now throws with a message identifying both conflicting agents. Dedup checked before building: no existing GitHub issue, PR, or commit in this repo addresses this specific multi-response resumption-ambiguity pattern. Verified: all 53 pre-existing tests in functions_test.ts pass unmodified against the patched source (no regression), plus 2 new tests (55 total). Broader core/test/runner/ suite (6 files, 152 tests, covering determineAgentForResumption's actual callers) passes with no regressions. tsc --noEmit, eslint, and prettier --check all clean.
Contributor
|
Hi @kalenkevich, I have checked the issue and validated the proposed changes. I was able to reproduce the issue. Could you please review this PR? |
Varun-S10
added
the
needs review
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.
fix in google/adk-python (commit 5449314) while auditing a routine commit batch -- adk-python's
Runner._resolve_invocation_idhad the identical gap in the Python port of this same resumption logic.findMatchingFunctionCallresolved which agent to resume after a tool/LRO boundary using onlyfunctionResponses[0].idfrom the last session event. A single event can carry responses answering calls from different agents at once (e.g. two long-running operations from sibling sub-agents completing together and being resumed in one message). Resolving from only the first response silently attributed the rest to whichever agent's call happened to come first.Dynamically confirmed before fixing with a PoC: two sibling agents each raising their own long-running call, resumed together in one event, resolved to only the first agent -- completely silent that the second response belonged to a different agent.
Fix mirrors adk-python's exact fail-closed philosophy: every response in the last event is checked, and if they resolve to calls from more than one distinct agent, the function throws rather than picking one.
Verified: all 53 pre-existing tests pass unmodified, plus 2 new tests (55 total). Broader
core/test/runner/suite (6 files, 152 tests) passes with no regressions.tsc --noEmit,eslint,prettier --checkall clean. Dynamically confirmed by reverting the fix in isolation and reproducing the exact silent-misattribution PoC before restoring.