triage: parallel tool-call turns send `tool_result` blocks one message too late, so the next request is rejected with 400
维护者通常 1 天内回复
还没有人认领这个 Issue。
- #3360 来自 @c01dsummer —— 已关闭,未合并
评估
调研方向
Read convert_messages() in rust/crates/rusty-claude-cli/src/main.rs and inspect the multi_tool_turn_roundtrip scenario in mock-anthropic-service. The issue proposes merging adjacent tool-result messages and extending regression coverage to check the captured request body. Done means all tool results for one assistant turn appear together in the immediately following message; a linked pull request is already open.
由索引模型根据 Issue 内容生成。
描述
Initial classification
actionable-bug
Evidence
Reported symptom. A claw REPL turn that issues two tool calls at once ends with the
provider rejecting the follow-up request:
✘ ❌ Request failed
[error-kind: api_http_error]
error: api returned 400 Bad Request (invalid_request_error): messages.3:`tool_use` ids were found
without `tool_result` blocks immediately after: call_01_4QJqcZ0075kla1ILwra75582. Each `tool_use`
block must have a corresponding `tool_result` block in the next message. (request_id: cfd...)
Reproduction. In an interactive claw session, send a prompt that makes the model request two
tools in one assistant turn (the session below asked to investigate a directory; the model emitted
ls-style bash calls twice). The first tool-result message pairs, the second does not, and the
request that follows is rejected with HTTP 400.
The durable session log written by that run shows the shape directly — this is
.claw/sessions/e49619b247aa3fce/session-1792170907799-0.jsonl, message records 1-5:
[3] assistant blocks=[thinking, thinking, tool_use, tool_use] <- two calls in ONE message
[4] tool blocks=[tool_result] <- call_00_8mxD6kU9VooBxwZzfYpO5328
[5] tool blocks=[tool_result] <- call_01_4QJqcZ0075kla1ILwra75582
Root cause. runtime records one MessageRole::Tool message per tool call, and
convert_messages() in rust/crates/rusty-claude-cli/src/main.rs turned each of them into its own
wire message. The Anthropic Messages API requires every tool_use of an assistant message to be
answered by tool_result blocks in the single message that follows it, so the wire history
became:
messages.3 assistant [thinking, thinking, tool_use, tool_use]
messages.4 user [tool_result] call_00_8mxD6kU9VooBxwZzfYpO5328 <- paired
messages.5 user [tool_result] call_01_4QJqcZ0075kla1ILwra75582 <- one message too late
Single-call turns are unaffected, which is why this only appears when the model requests several
tools at once. preflight_message_request only checks context length, and the OpenAI-compat path
has sanitize_tool_message_pairing while the Anthropic path has no equivalent.
Local verification of the failure mode. Replaying the session's message list through the
pre-fix convert_messages logic reproduces the provider's complaint verbatim, including the id it
names:
messages.3 assistant tool_use=['call_00_8mxD6kU9VooBxwZzfYpO5328', 'call_01_4QJqcZ0075kla1ILwra75582']
messages.4 tool_result=['call_00_8mxD6kU9VooBxwZzfYpO5328'] -> VIOLATION
==> messages.4: `tool_use` ids were found without `tool_result` blocks immediately after: call_01_4QJqcZ0075kla1ILwra75582
Proposed fix (offered, not applied here). Merge a run of adjacent tool-result messages into the
one user message that follows the assistant turn, extending only a message whose content is tool
results and nothing else. A regression test can drive the real binary against
mock-anthropic-service's multi_tool_turn_roundtrip scenario and assert the pairing contract on
the captured request body; run against the pre-fix code it fails with exactly the payload above.
Two further defects surfaced in the same session and are recorded as ROADMAP #836 (terminal-scope
record paths exceed the APFS 1024-byte total-path limit for a maximal key, invisible to the ubuntu
CI job because Linux PATH_MAX is 4096) and #838 (the missing-credential error never mentions a
configured non-Anthropic ANTHROPIC_BASE_URL).
Safe next action
Maintainer review of the proposed fix shape. A ready branch exists at
https://github.com/c01dsummer/claw-code/pull/1 (fork PR, closed as superseded because the review
target is this repository). If a same-repo PR is preferred so that CI runs without the
first-time-contributor workflow approval, I can open one; the diff is 574/-68 across 9 files and
carries its own unit and integration coverage plus the ROADMAP entries.
- I did not close, merge, or mutate remote state as part of this triage-only report.
- I checked for duplicates or related PRs/issues before recommending action. (searched this
repository for existingtool_use/tool_resultpairing reports: none found) - If this touches credentials, security, or private data, I avoided public reproduction details
and routed to the appropriate private/security path. (no credentials in this report)
- 主要语言
- Rust
- 星标
- 195k
- 派生
- 108k
- 平均合并
- 1 天 15 小时
- 30 天内合并 PR
- 44
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
ultraworkers/claw-code 的其他 Issue
-
GJC compatibility campaign: Rust fork-in-spirit of gajae-code可能已有人在做 @Yeachan-Heo 于 11 天前认领。 未关闭
ultraworkers/claw-code#3319 · 1 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
查看 ultraworkers/claw-code 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 85/100
farion1231/cc-switch#8829 ·
维护者通常 1 天内回复
-
bug ci good first issue
难度 2/5 1-3 小时 新手友好度 88/100
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 92/100
longbridge/gpui-kit#3677 ·
维护者通常 1 天内回复
-
E-pr-welcome
难度 2/5 1-3 小时 新手友好度 77/100
seanmonstar/reqwest#3121 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 68/100
ilya-zlobintsev/LACT#1235 ·
维护者通常 1 天内回复