[aiyili]

Fixes #3114

Problem

Toolkit.callTool(ToolCallParam) → ToolExecutor.execute(param) → executeCore — on the default zero-interceptor branch the returned block is never passed through withIdAndName, so any tool implementation that doesn't set id/name itself (most built-ins) returns a block with null id/name. The batch path (callTools → executeWithInfrastructure) always stamps. A caller following callTool's own javadoc gets a result it cannot pair back to the call.

Fix

The id/name backfill moved into applyResultErrorMapping(...) — the stage both branches already share — so the zero-interceptor and interceptor branches stamp identically, and the interceptor branch's duplicate map was removed. The batch path is untouched (executeWithInfrastructure stamps unconditionally downstream).

Test

ToolExecutorTest.callToolStampsIdAndName: register the add tool, call it via toolkit.callTool(...) with a ToolUseBlock carrying id="call-single-3114" — the returned block must have that id and name add; the same block via callTools must stamp identically. Fails on main (id is null).

[aiyili]

You're right — and my apologies: #3130 predates mine by weeks and I missed it in the pre-claim sweep (I only scanned the first page of open PRs, sorted by creation date, and #3130 had already aged past that page). That's on me.

Facts for the maintainers, since both PRs are now on the table:

• fix(core): route callTool through shared tool infrastructure #3130 (opened 2026-09-13): 29 commits / 14 files, currently dirty — it has not been rebased since fix(harness): sandbox edit generated python3 -c program with literal sequences (SyntaxError) #3226 and Refactor: separate the UNVERSIONED write path from the CAS branch in JdbcAgentStateStore #3273 (and related refactors) landed on main.
• fix(core): stamp id/name on the Toolkit.callTool single-call path #3686 (mine, opened yesterday): 1 commit / 2 files, rebased onto current main (head 5712934), same fix shape — the backfill lives in the shared applyResultErrorMapping stage rather than rerouting callTool through executeWithInfrastructure, so the single-call path keeps its no-scheduling/no-retry semantics and only gains the id/name stamp.

My suggestion: since #3130 has three weeks of history and review context, it should stay the canonical thread if you (KIM406) can rebase it — happy to review and close mine. If rebasing #3130 is not practical, #3686 is mergeable as-is and I'll maintain it. Either way the duplication ends with the next maintainer pass — I won't push further commits to #3686 unless asked.

[aiyili]

CI failure was mine — the pushed ToolExecutor.java violated Spotless (the re-wrapped indentation of the interceptor branch after the backfill moved). Fixed in 0417bfc (formatting only, no behavior change; verified the only delta vs the previous head is the re-indentation). The Windows job failed on the same spotless check cascading, so a rerun should go green.