Description
Describe the bug
The merge_parallel_function_response_events function (L484) in src/google/adk/flows/llm_flows/functions.py generates a new invocation_id using Event.new_id() for function_response data, instead of reusing the base_event's invocation_id.
This leads to function_response data being associated with a separate invocation ID (in the event ID format), making it impossible to query this data by the original invocation_id. When aggregating data, this often results in the function_response data not being correctly included within its respective invocation.
To Reproduce
Currently, I don't have a direct set of reproduction steps that can be run as a simple script without access to internal ADK testing environments or more complex setups. However, the issue can be observed by inspecting the invocation_id of function_response events generated by the merge_parallel_function_response_events function and comparing them to the invocation_id of the base_event from which they originated.
Expected behavior
The function_response data should retain the same invocation_id as the function_call that triggered it and the base_event it belongs to. This would allow for proper data aggregation and querying based on the invocation_id.
Screenshots
N/A
Desktop (please complete the following information):
- OS: macOS
- Python version(python -V): 3.12.10
- ADK version(pip show google-adk): 1.2.1
Additional context
The primary concern is data consistency and queryability. By generating a new invocation_id, the function_response effectively becomes an orphaned event in terms of its relation to the original invocation, complicating debugging, monitoring, and analysis of LLM flow executions. It would be beneficial to understand the rationale behind generating a new ID in this specific case, as it deviates from the expected behavior of keeping related events under a single invocation ID.