Skip to content

fix(aws-strands): carry ToolMessage.error onto the TypeScript adapter's tool results - #2365

Open
TheSeydiCharyyev wants to merge 1 commit into
ag-ui-protocol:mainfrom
TheSeydiCharyyev:fix/2362-strands-ts-tool-error-status
Open

fix(aws-strands): carry ToolMessage.error onto the TypeScript adapter's tool results#2365
TheSeydiCharyyev wants to merge 1 commit into
ag-ui-protocol:mainfrom
TheSeydiCharyyev:fix/2362-strands-ts-tool-error-status

Conversation

@TheSeydiCharyyev

Copy link
Copy Markdown
Contributor

Fixes #2362. Completes #2306 for the adapter it did not list.

The gap

#2306 named four AG-UI → framework tool conversions and #2317 fixed all four, but integrations/aws-strands/typescript was not on that list. The TypeScript adapter never read ToolMessage.error at all — every error in agent.ts was an exception message or a hook_error event — so on this adapter a client-reported frontend tool failure still reached the model as a success.

Three sites, two of them the twins of code already merged on the Python side:

site before Python twin
_buildStrandsHistory status: "success" as const agent.py, fixed in #2317
buildSnapshotMessages rebuilt the tool message without error / encryptedValue _build_snapshot_messages, fixed in #2317
convertMessagesForStrandsSeed status: "success" as const none — the seed path is TypeScript only

The change

Same rule as #2306: derive the framework flag from the presence of error, no sentinel.

  • _buildStrandsHistory and convertMessagesForStrandsSeedstatus is "error" when the AG-UI message carries error, "success" otherwise.
  • buildSnapshotMessageserror and encryptedValue are copied onto the echo. They are set only when the client set them, matching how toolCalls is handled a few lines above, so a snapshot for a message without them keeps exactly the shape it has today.

No type change was needed: ToolMessageSchema.error is already z.string().optional() in @ag-ui/core.

Tests

vitest run on integrations/aws-strands/typescript: 246 passed — 241 before this branch, plus 5. tsc --noEmit is clean.

  • history-replay.test.ts — an errored tool message reaches Strands as status: "error"; a successful one stays "success". Both go through run() rather than calling the helper directly.
  • seed-messages.test.ts — two results in one turn, one failed and one not, get independent statuses.
  • messages-snapshot.test.ts — the echo keeps error and encryptedValue; a message without them is echoed unchanged, with no new keys.

Checked that they fail for the right reason: with the three edits reverted, exactly those 3 tests fail and the other 31 in those files stay green.

Notes

src/agent.ts does not pass Prettier on this branch, but it already does not on main — the reported lines (1815, 1848, 2340) are untouched by this PR. I left the file alone rather than mixing a reformat into the diff; the lines added here are Prettier-clean.

…'s tool results

The TypeScript adapter never read ToolMessage.error. ag-ui-protocol#2306 listed four conversion sites and ag-ui-protocol#2317 fixed all of them, but aws-strands/typescript was not on that list, so a client-reported frontend tool failure still reached the model as a success.

Three sites: _buildStrandsHistory and convertMessagesForStrandsSeed both hardcoded the Bedrock toolResult status to success, and buildSnapshotMessages rebuilt the client's own tool message without its error and encryptedValue fields.
@TheSeydiCharyyev
TheSeydiCharyyev requested a review from a team as a code owner August 11, 2026 13:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: aws-strands TypeScript adapter never carries ToolMessage.error onto the Bedrock toolResult status

1 participant