[Bug]:: Message: Invalid tool result IDs: [call_01_w7wlz4ch9Hiw4Um74zwv8117]. Expected: [call_00_OugZmGqpB71ykFO5IjxM8342] #3043

（大模型调试了一天发现的问题）
Describe the bug Resuming a run with external-execution ("client/frontend") tool results can fail with IllegalStateException: Invalid tool result IDs: [...] Expected: [...], permanently wedging the session.

ReActAgent.CallExecution.validateAndAddToolResults fails the whole run whenever any submitted tool-result ID is not in the pending tool-call IDs of the agent's last assistant message. With AG-UI clients that replay their full transcript (e.g. CopilotKit headless + browser-side frontend tools), a later user message can carry stale tool results from an earlier assistant round (the round whose result was already consumed or whose required result lives mid-transcript). After the first such submission the run dies with a RUN_ERROR, and because the stale result stays in the client transcript, every subsequent user message in the thread fails the same validation forever.

Observed across multiple reproductions:

Invalid tool result IDs: [call_01_7icKHvTMy32ReIAnjkgu2856]. Expected: [call_00_EEGrx8VtxFIpkJarXNXD6198]
Invalid tool result IDs: [call_01_SxJ4HtkNkradgAcGZZBj3288]. Expected: [call_00_BibzeGa9V4O4xDeIvZju4111]
The "Expected" ID always refers to an assistant tool-call message that sits earlier in the client transcript (its result was trimmed away by AguiRequestProcessor.extractLatestUserMessage, which only forwards messages that trail the client's last assistant message), while the "Provided" ID belongs to a newer round that the server is no longer waiting for.

To Reproduce Steps to reproduce the behavior:

Stand up an AG-UI runtime (AguiMvcController) whose agent (ReActAgent, stateful per thread) exposes a mix of server tools and client-executed tools (schema-only / ToolSuspendException tools).
Drive it from a transcript-replaying client that executes client tools in the browser:
Java

// First run -> assistant message asks for a client tool "external_api" (id ext1), run suspends.
agent.streamEvents(List.of()).blockLast();
// Resume #1 -> client replies with the correct result for ext1; server resumes.
agent.streamEvents(List.of(toolResultMsg("ext1", "ok"))).blockLast();
// Later: agent produces ANOTHER assistant tool round, then the user sends a new message
// while the client transcript still replays the (already consumed) "ext1" result as trailing.
Msg stale = Msg.builder().role(MsgRole.TOOL)
.content(ToolResultBlock.builder().id("ext1")...build()).build();
Msg fresh = Msg.builder().role(MsgRole.USER).textContent("please continue").build();
agent.streamEvents(List.of(stale, fresh)).collectList().block(); // throws
See error:

IllegalStateException: Invalid tool result IDs: [ext1]. Expected: []
(In production the payload shape is the AG-UI run resume body; the stack surfaces on the client as a RUN_ERROR event, code agent_run_error_event.)

Trigger conditions observed in real traffic:

The model emits more than one tool call in a single assistant message (e.g. one client tool + one server tool in the same reply). The client splits them into separate local assistant rounds, submits them in separate resume requests, and later replays already-accepted results.
A new user message is sent while an older external-execution round is still "pending" server-side but already resolved on the client.
Expected behavior A resumed request that carries tool results should be tolerant of stale results:

Tool-result IDs that are not among the current pending IDs should be ignored (logged), not treated as a fatal protocol violation.
If the input only contains stale results plus a real user text message, the abandoned pending tool round should be cancelled (synthetic error result, same as the existing enablePendingToolRecovery behavior) and the new user message should proceed as a fresh instruction — instead of throwing forever on every later turn.
Duplicate IDs and "partial results + text" should still be rejected exactly as today.
Error messages

java.lang.IllegalStateException: Invalid tool result IDs: [call_01_7icKHvTMy32ReIAnjkgu2856]. Expected: [call_00_EEGrx8VtxFIpkJarXNXD6198]
at io.agentscope.core.ReActAgent$CallExecution.validateAndAddToolResults(ReActAgent.java:2221)
Surfaced over AG-UI as:

JSON

{
"type": "run-error",
"code": "INVALID_INPUT_ERROR",
"message": "Invalid tool result IDs: [call_01_...]. Expected: [call_00_...]"
}
Environment (please complete the following information):

AgentScope-Java Version: 2.0.3-SNAPSHOT (also confirmed affected in 2.0.2 — same ReActAgent.validateAndAddToolResults code)
Java Version: [17+ expected; reproduce under your JDK]
OS: Windows
Additional context Root-cause chain:

ReActAgent.validateAndAddToolResults (private CallExecution method) treats every provided result ID not in pendingIds as a hard error.
With server-side memory enabled, AguiRequestProcessor.extractLatestUserMessage forwards only the messages after the client's last assistant message; the earlier round's real result (which the server actually needs) sits mid-transcript and is dropped.
Because the client keeps replaying that stale round on every subsequent request, the session never recovers — one bad round bricks all later turns in the thread.
Proposed fix (minimal, in validateAndAddToolResults):

Partition provided results into valid (in pendingIds) and stale (not pending). Log stale IDs at warn and drop them instead of throwing.
If no valid results remain and the input carries a non-tool-result user message, synthesize an ToolResultBlock.error for each still-pending call (same pattern as maybePatchPendingToolCalls / the shutdown-interrupt recovery) and add only the cleaned messages, so the new user instruction is handled by a fresh reasoning step.
Only throw when no valid results remain and there is no user text.
Strip stale ToolResultBlocks from the messages before appending to context to avoid unbounded duplicate growth.
A regression test for this shape (stale result + new user text resumes successfully and cancels the abandoned pending call) was validated against a local patched build of ReActAgentNewLoopReplyTest; all related suites (ReActAgentHitlTest, ReActAgentSummarizingTest, ReActAgentNewLoopReplyTest) stayed green. Happy to open a PR with the fix and test if maintainers agree with the direction.

Error messages

Code: agent_run_error_event
Message: Invalid tool result IDs: [call_01_w7wlz4ch9Hiw4Um74zwv8117]. Expected: [call_00_OugZmGqpB71ykFO5IjxM8342]
Context: {
"source": "onRunErrorEvent",
"event": {
"type": "RUN_ERROR",
"timestamp": 1788838954967,
"message": "Invalid tool result IDs: [call_01_w7wlz4ch9Hiw4Um74zwv8117]. Expected: [call_00_OugZmGqpB71ykFO5IjxM8342]",
"code": "INVALID_INPUT_ERROR",
"threadId": "476270bb-8bd3-4d2d-a96b-7519a0cce1b5",
"runId": "937f2963-789c-4310-96c3-907c90d8c436"
},
"runtimeErrorCode": "INVALID_INPUT_ERROR",
"agentId": "f_assistant"
}
Stack:
Error: Invalid tool result IDs: [call_01_w7wlz4ch9Hiw4Um74zwv8117]. Expected: [call_00_OugZmGqpB71ykFO5IjxM8342]
at Object.onRunErrorEvent (http://localhost:5173/node_modules/.vite/deps/directive-CFNeHBg4.js?v=dab07746:20263:36)
at http://localhost:5173/node_modules/.vite/deps/directive-CFNeHBg4.js?v=dab07746:9454:88
at N (http://localhost:5173/node_modules/.vite/deps/directive-CFNeHBg4.js?v=dab07746:9032:17)
at async http://localhost:5173/node_modules/.vite/deps/directive-CFNeHBg4.js?v=dab07746:9454:39

Environment (please complete the following information):
agentscope 2.0.3-snapsho
Additional context
Add any other context about the problem here.