toolResults sent to AWS/Bedrock models rejected for missing json subdocument #7874

Open
opened 2026-02-16 18:08:32 -05:00 by yindo · 3 comments
Owner

Originally created by @jeblackburn-mdb on GitHub (Jan 28, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description

When my sessions get complicated and involve many tool calls, it appears that some of them return toolResult payloads that are rejected by AWS/Bedrock (regardless of the model used).

I wish I could give you reproduction steps, but they amount to something like this:

Result

The streaming consumer is eventually fed an error message

"error: The format of the value at messages.34.content.0.toolResult.content.0.json is invalid. Provide a json object for the field and try again."

Expected Result

Not a crash/session-ending event.

Notes

I spent some time looking around and found this issue with the AWS team. In short, they reject toolResults that have content that is not minimally a JSON object. This looks suspiciously like the error I'm seeing, and I'm wondering if it's an issue we could work around on the client side.

Plugins

Defaults

OpenCode version

Latest, from Git.

Steps to reproduce

Repro Steps

  • Configure OpenCode to use a local gateway
  • Specify a Bedrock model.
  • Do some workflow that includes tool uses that don't have any obvious return value (file write, db write, who knows exactly).
  • Observe the error above. The server and TUI continue to work, but this session is kaput.
  • Specify e.g. an Azure-hosted model (GPT5, in my case).
  • Observe the issue does not appear.

Screenshot and/or share link

No response

Operating System

Windows 10 and also MacOS 26.2

Terminal

PowerShell and also iTerm2

Originally created by @jeblackburn-mdb on GitHub (Jan 28, 2026). Originally assigned to: @rekram1-node on GitHub. ### Description When my sessions get complicated and involve many tool calls, it appears that some of them return toolResult payloads that are rejected by AWS/Bedrock (regardless of the model used). I wish I could give you reproduction steps, but they amount to something like this: ## Result The streaming consumer is eventually fed an error message ``` "error: The format of the value at messages.34.content.0.toolResult.content.0.json is invalid. Provide a json object for the field and try again." ``` ## Expected Result Not a crash/session-ending event. ## Notes I spent some time looking around and found [this issue](https://github.com/aws/aws-sdk-js-v3/issues/7330) with the AWS team. In short, they reject toolResults that have content that is not minimally a JSON object. This looks suspiciously like the error I'm seeing, and I'm wondering if it's an issue we could work around on the client side. ### Plugins Defaults ### OpenCode version Latest, from Git. ### Steps to reproduce ## Repro Steps - Configure OpenCode to use a local gateway - Specify a Bedrock model. - Do some workflow that includes tool uses that don't have any obvious return value (file write, db write, who knows exactly). - Observe the error above. The server and TUI continue to work, but this session is kaput. - Specify e.g. an Azure-hosted model (GPT5, in my case). - Observe the issue does not appear. ### Screenshot and/or share link _No response_ ### Operating System Windows 10 and also MacOS 26.2 ### Terminal PowerShell and also iTerm2
yindo added the windowsbug labels 2026-02-16 18:08:32 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 28, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #10259: Compaction fails with Bedrock: toolConfig not included when conversation has tool history (Bedrock validation errors with tool-related content)
  • #8312: Bug: Session corrupted when tool execution is aborted - missing tool_result causes API rejection (Missing or malformed toolResult blocks causing API validation failures)

These issues both involve toolResult content validation failures with AWS Bedrock and similar providers. Feel free to ignore if your specific case involves a different scenario.

@github-actions[bot] commented on GitHub (Jan 28, 2026): This issue might be a duplicate of existing issues. Please check: - #10259: Compaction fails with Bedrock: toolConfig not included when conversation has tool history (Bedrock validation errors with tool-related content) - #8312: Bug: Session corrupted when tool execution is aborted - missing tool_result causes API rejection (Missing or malformed toolResult blocks causing API validation failures) These issues both involve toolResult content validation failures with AWS Bedrock and similar providers. Feel free to ignore if your specific case involves a different scenario.
Author
Owner

@jeblackburn-mdb commented on GitHub (Jan 28, 2026):

I added some logging to the server and captured the messages that I believe triggered the error.

Given an error like this:

"error: The format of the value at messages.24.content.0.toolResult.content.0.json is invalid. Provide a json object for the field and try again."

I scraped the list of messages being prepared for sending in llm.ts and found that the message that is consistently in the index that matches the error message is the tool-result for todowrite. Here's an example.

{'role': 'tool',
'content': [{'type': 'tool-result',
   'toolCallId': 'tooluse_RK4WGhiJSAubWcqJyk1WCA',
   'toolName': 'todowrite',
   'output': {'type': 'text',
    'value': '[\n  {\n    "id": "1",\n    "content": "Create BookJdbcDaoIntegrationTest.java in appropriate test directory",\n    "status": "in_progress",\n    "priority": "high"\n  },\n  {\n    "id": "2",\n    "content": "Implement test setup with TestContainers Oracle configuration",\n    "status": "pending",\n    "priority": "high"\n  },\n  {\n    "id": "3",\n    "content": "Write test: verify book not found initially, insert via DA DAO, read via common-service DAO",\n    "status": "pending",\n    "priority": "high"\n  },\n  {\n    "id": "4",\n    "content": "Write test: verify mergeBookDetails flow (NBOOK + APP_BOOK + TRANSIT)",\n    "status": "pending",\n    "priority": "high"\n  },\n  {\n    "id": "5",\n    "content": "Write test: verify getNewBookDetails retrieval methods",\n    "status": "pending",\n    "priority": "medium"\n  }\n]'}}]}

Is it possible that the Bedrock servers are unhappy with "value"'s JSON string containing a "content" attribute that's a string? I tried and failed to get the agent to send that tool-result as markdown or text instead of JSON, but nope.

@jeblackburn-mdb commented on GitHub (Jan 28, 2026): I added some logging to the server and captured the messages that I believe triggered the error. Given an error like this: ``` "error: The format of the value at messages.24.content.0.toolResult.content.0.json is invalid. Provide a json object for the field and try again." ``` I scraped the list of messages being prepared for sending in llm.ts and found that the message that is consistently in the index that matches the error message is the tool-result for todowrite. Here's an example. ``` {'role': 'tool', 'content': [{'type': 'tool-result', 'toolCallId': 'tooluse_RK4WGhiJSAubWcqJyk1WCA', 'toolName': 'todowrite', 'output': {'type': 'text', 'value': '[\n {\n "id": "1",\n "content": "Create BookJdbcDaoIntegrationTest.java in appropriate test directory",\n "status": "in_progress",\n "priority": "high"\n },\n {\n "id": "2",\n "content": "Implement test setup with TestContainers Oracle configuration",\n "status": "pending",\n "priority": "high"\n },\n {\n "id": "3",\n "content": "Write test: verify book not found initially, insert via DA DAO, read via common-service DAO",\n "status": "pending",\n "priority": "high"\n },\n {\n "id": "4",\n "content": "Write test: verify mergeBookDetails flow (NBOOK + APP_BOOK + TRANSIT)",\n "status": "pending",\n "priority": "high"\n },\n {\n "id": "5",\n "content": "Write test: verify getNewBookDetails retrieval methods",\n "status": "pending",\n "priority": "medium"\n }\n]'}}]} ``` Is it possible that the Bedrock servers are unhappy with "value"'s JSON string containing a "content" attribute that's a string? I tried and failed to get the agent to send that tool-result as markdown or text instead of JSON, but nope.
Author
Owner

@jeblackburn-mdb commented on GitHub (Jan 29, 2026):

Confirmed this is the case. It's my assumption that any LLM call made to a Bedrock-hosted model, and includes text that looks like JSON, and includes keywords they think should be structured a certain way, will have this problem.

I confirmed it by hacking the todowrite Tool to return results that are plain text, not JSON.stringify(...) text. I'm not sure if you want to fix this my way (with a more complex serialization of todo list items), or another way, or ignore it altogether. At least we know where the problem lies.

@jeblackburn-mdb commented on GitHub (Jan 29, 2026): Confirmed this is the case. It's my assumption that any LLM call made to a Bedrock-hosted model, and includes text that looks like JSON, and includes keywords they think should be structured a certain way, will have this problem. I confirmed it by hacking the todowrite Tool to return results that are plain text, not JSON.stringify(...) text. I'm not sure if you want to fix this my way (with a more complex serialization of todo list items), or another way, or ignore it altogether. At least we know where the problem lies.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#7874