Fix: Process function_response from separate request by searching full history Fixes #3531

[miguelabdonsh]

Problem

When sending a function_response via a separate /run_sse request (e.g., async
job completion callback), _rearrange_events_for_latest_function_response
raised:

ValueError: No function call event found for function responses ids

The function only searched events in the current request context
(filtered_events), not the full session history. When a function_response
arrived in a separate request, it couldn't find the matching function_call from
the previous request.

Regression from ADK 1.17.0 → 1.18.0.

Solution

Modified _rearrange_events_for_latest_function_response to search the full
session history (rewind_filtered_events) instead of only current request
events.

Changes in src/google/adk/flows/llm_flows/contents.py:
- Added all_events parameter (line 128)
- Search in all_events if provided, otherwise fall back to events (line
165-169)
- Pass rewind_filtered_events when calling the function (line 440-441)

Testing

✅ All 30 existing tests in test_contents*.py pass
✅ New test test_function_response_in_separate_request.py verifies fix
✅ Test simulates async scenario: function_call in early session history,
function_response arrives later

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Summary of Changes

Hello @miguelabdonsh, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves a critical regression that prevented the correct processing of asynchronous function responses in the system. By extending the search scope for corresponding function calls to the entire session history, the change ensures that function_response events, particularly those arriving in separate requests, are properly matched and handled, restoring robust support for asynchronous tool execution workflows.

Highlights

• Problem Addressed: Fixed a ValueError (No function call event found for function responses ids) that occurred when a function_response was sent via a separate /run_sse request. This regression from ADK 1.17.0 to 1.18.0 was due to the function only searching the current request context, not the full session history.
• Solution Implemented: The _rearrange_events_for_latest_function_response function was modified to search the full session history (rewind_filtered_events) to correctly find the matching function_call from previous requests.
• Code Changes: The _rearrange_events_for_latest_function_response function in src/google/adk/flows/llm_flows/contents.py now accepts an optional all_events parameter, which is used for searching if provided. The function call to this method was updated to pass rewind_filtered_events.
• Testing: All existing tests passed, and a new test file (test_function_response_in_separate_request.py) was added to specifically verify the fix for asynchronous scenarios, simulating a function_call in early history and a function_response arriving later in a separate request.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[adk-bot]

Response from ADK Triaging Agent

Hello @miguelabdonsh, thank you for your contribution!

Before we can merge this PR, you'll need to sign a Contributor License Agreement (CLA). You can find more information in our contribution guidelines.

Once the CLA is signed, we can proceed with the review. Thanks!

[gemini-code-assist]

Code Review

This pull request addresses a regression where a function_response arriving in a separate request could not find its corresponding function_call. The fix correctly expands the search to the full session history. The addition of a new unit test to validate this asynchronous scenario is a great improvement. However, I've identified a critical issue in the implementation where an index from the full history is incorrectly used on a filtered list of events, which could lead to errors. Please see my detailed comment.

[gemini-code-assist]

There appears to be a critical issue with how the index from this search is used. The function_call_event_idx is calculated by iterating over search_events (which can be the full history all_events), but this index is later used to slice and access elements in events (the filtered list).

Since events is a processed and filtered version of search_events, their indices are not interchangeable. This will likely lead to an IndexError or incorrect logic when the lists differ in length or content.

To resolve this, after finding the matching event at idx in search_events, you should find the corresponding index of that same event within the events list (for example, by matching event.id). This new, correct index should then be used for all subsequent operations on events.