[Bug]: Bedrock Converse streaming produces string `tool_kwargs` in `ToolCallBlock` instead of dict

[jimhotchkin-wf]

Bug Description

The Bedrock Converse adapter's streaming methods (stream_chat and astream_chat) construct ToolCallBlock objects with tool_kwargs as a raw JSON string instead of a parsed dict. This breaks cross-provider workflows where chat history from a Bedrock streaming session is later consumed by another provider's adapter (e.g., Google GenAI), which expects tool_kwargs to be a dict.

Root Cause

The AWS Bedrock Converse streaming API (ConverseStream) delivers tool use input via ToolUseBlockDelta.input as a string type. The adapter correctly concatenates these partial string chunks:

# base.py, stream_chat / astream_chat
current_tool_call["input"] += tool_use_delta["input"]

But when constructing ToolCallBlock, it passes the accumulated string directly without parsing:

ToolCallBlock(
    tool_kwargs=tool_call.get("input", {}),  # ← still a JSON string, not a dict
    tool_name=tool_call.get("name", ""),
    tool_call_id=tool_call.get("toolUseId"),
)

This pattern appears at 6 locations in base.py (lines 593, 649, 693, 877, 933, 978 in v0.14.9), all within the streaming code paths.

Why the non-streaming path works

The non-streaming Converse API returns ToolUseBlock.input as a JSON value, which boto3 deserializes to a Python dict. So the non-streaming _get_content_and_tool_calls method at line ~430 works correctly — tool_usage.get("input", {}) is already a dict.

Internal inconsistency

The adapter's own get_tool_calls_from_response method already defensively handles string tool_kwargs:

if isinstance(tool_call.tool_kwargs, str):
    try:
        argument_dict = parse_partial_json(tool_call.tool_kwargs)
    ...

This suggests the developers were aware that strings could appear, but the fix was applied at the consumption site rather than at the source.

Downstream Impact

Adapters that receive ToolCallBlock with string tool_kwargs may fail. For example, the Google GenAI adapter (llama_index/llms/google_genai/utils.py) constructs:

google.genai.types.FunctionCall(
    name=block.tool_name,
    args=cast(Dict[str, Any], block.tool_kwargs)  # ← Pydantic rejects strings
)

This produces:

pydantic_core.ValidationError: 1 validation error for FunctionCall
args
  Input should be a valid dictionary [type=dict_type, input_value='{"document_id": "..."}', input_type=str]

Any workflow that persists chat history from a Bedrock streaming session and replays it through a different provider will hit this.

Suggested Fix

Parse the accumulated JSON string into a dict when constructing ToolCallBlock in the streaming code paths. A minimal fix at each of the 6 construction sites:

import json

# Replace:
tool_kwargs=tool_call.get("input", {})

# With:
tool_kwargs=json.loads(tool_call["input"]) if isinstance(tool_call.get("input"), str) else tool_call.get("input", {})

Alternatively, the parsing could happen once at the contentBlockStop event (when the tool use block is complete), converting current_tool_call["input"] from string to dict at that point before any ToolCallBlock is constructed with the final value.

Version

llama-index-llms-bedrock-converse 0.14.9 (also confirmed still present on main).

Steps to Reproduce

Adapters that receive ToolCallBlock with string tool_kwargs may fail. For example, the Google GenAI adapter (llama_index/llms/google_genai/utils.py) constructs:

google.genai.types.FunctionCall(
    name=block.tool_name,
    args=cast(Dict[str, Any], block.tool_kwargs)  # ← Pydantic rejects strings
)

This produces:

pydantic_core.ValidationError: 1 validation error for FunctionCall
args
  Input should be a valid dictionary [type=dict_type, input_value='{"document_id": "..."}', input_type=str]

Any workflow that persists chat history from a Bedrock streaming session and replays it through a different provider will hit this.

Relevant Logs/Tracebacks

[dosubot]

Hi @jimhotchkin-wf! I'm Dosu and I’m helping the llama_index team.

Thanks for the detailed bug report. I investigated the current state of the code and have some observations:

The core issue is real, but the details differ from the report. The current base.py has 773 lines total [1], not the ~978+ implied by the report. Also, ToolCallBlock does not exist in the LlamaIndex codebase — tool calls are stored as raw dicts in ChatMessage.additional_kwargs["tool_calls"], and the class used downstream is ToolSelection.

What actually happens in streaming: The streaming code paths (stream_chat and astream_chat) accumulate the "input" field as a concatenated JSON string [2] [3] and yield ChatResponse objects with those raw dicts (containing string "input") in additional_kwargs["tool_calls"].

The get_tool_calls_from_response method already handles this correctly — it checks isinstance(tool_call["input"], str) and parses it via parse_partial_json() before constructing ToolSelection objects with a proper dict tool_kwargs [4].

So the Bedrock Converse adapter itself works end-to-end because the agent workflow calls get_tool_calls_from_response() which normalizes the string. However, the broader concern is valid: if another provider's adapter consumes the raw additional_kwargs["tool_calls"] dicts from a Bedrock streaming session (e.g., when persisting and replaying chat history cross-provider), it would encounter string "input" values instead of dicts.

Suggested fix location: Parsing current_tool_call["input"] from string to dict at the contentBlockStop event (when the tool use block is complete) would be the cleanest approach. This normalizes the data at the source so all downstream consumers — whether Bedrock's own get_tool_calls_from_response or another provider — see a dict. This is a one-line addition per streaming method rather than touching 6 construction sites.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[ayushh0110]

I'd like to work on this

Will go with the approach @dosu suggested — parsing current_tool_call["input"] from string to dict at the contentBlockStop event in both stream_chat and astream_chat. This normalizes the data at the source so all downstream consumers (including cross-provider replay) get a proper dict without needing changes at every construction site.

[ayushh0110]

Opened #21580 to fix this.

Instead of parsing at contentBlockStop as suggested by Dosu, I went with a _parse_tool_input() helper applied at each of the 6 ToolCallBlock construction sites. The contentBlockStop approach has a couple of issues — there's no handler for that event in the current code, and even if we added one, intermediate contentBlockDelta yields would still emit raw strings before it fires. The helper approach normalizes every yield (intermediate and final), requires no new event handlers, and matches the existing defensive pattern already used in get_tool_calls_from_response().