Skip to content

fix(core): replace parts[0] in telemetry and tools to support paralle… - #6604

Open
Harshitmishra001 wants to merge 1 commit into
google:mainfrom
Harshitmishra001:fix-systemic-parts-bug
Open

fix(core): replace parts[0] in telemetry and tools to support paralle…#6604
Harshitmishra001 wants to merge 1 commit into
google:mainfrom
Harshitmishra001:fix-systemic-parts-bug

Conversation

@Harshitmishra001

Copy link
Copy Markdown

This systemic fix replaces hardcoded parts[0] assumptions with correct name-based matching in telemetry tracing, artifact loading, MCP resource loading, and CLI tooling. This resolves issues like #5967 where parallel tools caused infinite loops or dropped telemetry.

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

2. Or, if no issue exists, describe the change:

If applicable, please follow the issue templates to provide as much detail as
possible.

Problem:
Across multiple subsystems (tracing.py, load_artifacts_tool.py, load_mcp_resource_tool.py, cli_record.py), the framework assumed that a function_response always resides at event.content.parts[0]. In parallel tool execution, multiple tools execute and return responses in the same content block, meaning indices are dynamic. This hardcoded assumption caused the framework to ignore tool responses entirely if they were located at parts[1] or higher, leading to infinite loops in tool calling (e.g., #5967) and dropped telemetry.

Solution:
Systematically refactored these subsystems to replace parts[0] lookups with robust loops that search the entire event.content.parts array for the function_response matching the current tool.name.

Testing Plan

Please describe the tests that you ran to verify your changes. This is required
for all PRs that are not small documentation or typo fixes.

Unit Tests:

  • I have added or updated unit tests for my change.
  • All unit tests pass locally.

Please include a summary of passed pytest results.
We updated test_spans.py (which was previously relying on the broken parts[0] assumption in its test fixtures) to map names correctly.

tests\unittests\telemetry\test_spans.py ................................ [ 30%]
........................................................................ [ 99%]
.                                                                        [100%]
======================= 105 passed, 2 warnings in 3.67s =======================

All >10,000 unit tests across the framework pass locally with this refactor.

Manual End-to-End (E2E) Tests:

Please provide instructions on how to manually test your changes, including any
necessary setup or configuration. Please provide logs or screenshots to help
reviewers better understand the fix.

Created a custom test script to manually construct types.Content events simulating multiple parallel tool outputs (e.g., parts=[Part(function_response=A), Part(function_response=B)]). Prior to the fix, passing this event into load_artifacts_tool caused the tool to drop the response for B. Post-fix, the loop correctly matches B by name and properly logs the tool context.

Checklist

  • I have read the CONTRIBUTING.md document.
  • I have performed a self-review of my own code.
  • I have commented my code, particularly in hard-to-understand areas.
  • I have added tests that prove my fix is effective or that my feature works.
  • New and existing unit tests pass locally with my changes.
  • I have manually tested my changes end-to-end.
  • Any dependent changes have been merged and published in downstream modules.

Additional context

This PR is a companion to PR #6595 (which fixed this exact issue for the Live flow signals). This PR addresses the remaining systemic occurrences in telemetry and native tools.

…l execution

This systemic fix replaces hardcoded parts[0] assumptions with correct name-based matching in telemetry tracing, artifact loading, MCP resource loading, and CLI tooling. This resolves issues like google#5967 where parallel tools caused infinite loops or dropped telemetry.
@adk-bot adk-bot added the core [Component] This issue is related to the core interface and implementation label Aug 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core [Component] This issue is related to the core interface and implementation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: Systemic failure in parallel tool execution (dropped tools, infinite loops) due to hardcoded parts[0] indexing

3 participants