[Bug]: aws-strands reports failed frontend tools as success on the session-manager path

[BenTaylorDev]

Describe the Bug

Follow-up to #2306, split out of the review of #2317.

#2317 carries AG-UI's ToolMessage.error onto Bedrock's toolResult.status in _build_strands_history (integrations/aws-strands/python/src/ag_ui_strands/agent.py:213), so a client-reported frontend tool failure reaches the model as a failure. That fix is correct, but it only applies on one of the adapter's run paths.

_build_strands_history has exactly one caller, gated at agent.py:1040:

replay_history = (
    self.config.replay_history_into_strands and session_manager is None
)
reconcile_session_results = (
    session_manager is not None
    and self.config.replay_history_into_strands
    and has_nonvoid_frontend_result
)
if replay_history:
    native_history = _build_strands_history(input_data.messages)   # <- #2317's fix applies here
    ...
elif reconcile_session_results:                                     # <- and nowhere in here

When a session_manager_provider is configured, the model reads the persisted Strands history rather than a rebuilt one. Those toolResult blocks are created by the proxy tool with status hardcoded to "success" (client_proxy_tool.py:58-59):

def _proxy_func(tool_use: ToolUse, **_kwargs: Any) -> ToolResult:
    return {
        "toolUseId": tool_use["toolUseId"],
        "status": "success",
        "content": [{"text": PROXY_RESULT_PLACEHOLDER}],
    }

and reconciliation rewrites only the content, never the status (session_reconcile.py:138):

tool_result["content"] = [{"text": pending_results[tool_use_id]}]

There is also no channel to carry the flag through: pending_results is typed Mapping[str, str] (session_reconcile.py:56) — native toolUseId → result text, with no error signal.

Net effect: on the session-manager path, a failed frontend tool call is still asserted to the model as having succeeded — the same bug #2306 describes, on a path the fix does not reach. The legacy branch (stream_async(user_message), history tracked by the session manager) has the same shape.

Steps to Reproduce

1. Configure a StrandsAgent with a session_manager_provider (so session_manager is not None), leaving replay_history_into_strands at its default True.
2. Have the frontend execute a tool and return an AG-UI ToolMessage with error set.
3. Inspect the toolResult block the model receives on the follow-up turn: content is the real result text, but status is "success".

The same run with no session_manager_provider takes the replay_history branch and correctly reports status: "error" after #2317.

Expected Behavior

A client-reported tool failure should reach the model as status: "error" regardless of whether a session_manager is configured. That likely means widening the reconcile channel to carry the flag alongside the text — e.g. pending_results becoming a mapping to (text, is_error) rather than str, with _correct_message writing tool_result["status"] when it rewrites tool_result["content"].

Why this is lower priority than it sounds

The default configuration is unaffected: replay_history_into_strands defaults to True (config.py:122) and session_manager defaults to None, so out-of-the-box deployments take the branch #2317 fixes. This gap is specific to deployments that configure persistence via session_manager_provider.

Environment

integrations/aws-strands/python, as of origin/main
Related: #2306, #2317, #2263

[TheSeydiCharyyev]

I would like to take this one — it continues #2317 and I already know this path.

I re-checked the claims against current main first. _build_strands_history has one production caller, at agent.py:1057, inside the replay_history branch. With a session_manager the run goes to reconcile_session_results instead, so the #2317 fix never runs there. The persisted blocks come from _proxy_func with "status": "success" hardcoded (client_proxy_tool.py:58), and _correct_message rewrites only content (session_reconcile.py:138). There is no channel for the flag today: pending_results is Mapping[str, str].

Plan, in the shape you sketched:

• agent.py:1015 — each frontend_results entry also carries the flag, read from msg.error.
• session_reconcile.py — resolve_native_ids returns native toolUseId -> (text, is_error), and _correct_message writes tool_result["status"] in the same place where it rewrites tool_result["content"].
• agent.py:1110 — the resolved_non_void comprehension unpacks the new value shape.
• Tests in test_session_reconcile.py: the 5 existing call sites move to the new shape, plus new cases for the persisted store and for the agent's in-memory history.

session_reconcile is not exported from __init__.py, so the signature change stays inside the package.

Two things I plan to keep out, so the PR stays on the reconcile channel:

1. The legacy branch at agent.py:1129. You note it has the same shape. There the real result reaches the model as a synthetic user message, so there is no toolResult block to stamp. That is a different change.

2. Void results. reconcile_session_results is gated on has_nonvoid_frontend_result (agent.py:1054), and ToolMessage.content is a required str. So a failed tool that returns content="" with error set never reaches reconciliation at all — it falls to the legacy path, and the placeholder keeps status: "success". Widening that gate changes when reconciliation runs, which is more than this issue asks for.

One question before I write it: on point 2, do you want the gate widened here (has_nonvoid_frontend_result or any error flag), or kept as a separate follow-up? My default is to leave it out and say so in the PR body.