The occurrence selector tells a per-call list from a single call's list
value by length alone. One test pinned the side where that is
unambiguous -- a 3-element list against 2 calls, replayed whole. The side
that decides whether the rule is safe is the other one: a tool called n
times whose single stored value is a list of length n. That case was
decided by the rule and described by no test, so it read as an oversight
rather than a decision.
Pin it at both readers. The replay reader in base_agent_runner and the
display reader on MessageAgentThought each get a two-call record whose
one stored value is a two-element list, asserting that call 1 reads
element 0 and call 2 reads element 1 -- what the rule does today. The
name says what the case concedes rather than what it asserts.
The docstrings say why the asymmetry is tolerable. observation values
are always str: ToolEngine.agent_invoke is typed
-> tuple[str, list[str], ToolInvokeMeta] and both runners store element
0, so a list under a tool name is not a shape any writer produces and
the length check is defensive there. tool_input values are json.loads of
the model's arguments with no shape check, so a legacy list-valued input
is possible in principle, and that is the side the collision can reach.
The selector is defined twice, identically, because models/ importing
from core/agent/ is the worse layering trade and the reverse is odd.
Neither copy is in the wrong place, so each now names the other and says
the duplication is deliberate -- enough for a future editor to find both.
No behaviour change: the condition, the ordering and the fallback are
untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The selector moved into models.model so the log reader and the replay
reader could share one definition. It moves back: the review thread on
this branch anchors to it in base_agent_runner, and relocating a symbol
mid-review costs the reviewer more than the duplicate saves.
base_agent_runner is byte-identical to what it was before the move.
models.model keeps its own local copy with the same logic, so a change
to how a per-call payload is recognised has to be made in both places --
noted here rather than fixed, because that recognition rule is an open
question on the review.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The console agent log builds one entry per name in the ";"-joined tool
column, then looks each name up in a dict keyed by tool name. A tool
called twice in one turn produced two entries reading the same key, so
both showed the same data -- the display the reproduction in #16220
describes.
Keeping every call's input and observation apart, as this branch already
did, changed what those two entries show without making them right: each
one showed both calls' data instead of one call's data twice.
Read the persisted payloads per call instead. MessageAgentThought now
exposes tool_inputs_per_call, tool_outputs_per_call and
tool_metas_per_call, one entry per entry in tools, in call order, and
get_agent_logs walks them alongside the names. A name whose stored value
is not one value per call gives the same value to each of its calls, so
every record written before those calls were kept apart renders exactly
as it renders today.
That makes tool_invoke_meta safe to group the same way, which it now is.
It carries the provider, the duration and the error the log shows for
each displayed call, so leaving it name-keyed would have left a repeated
tool showing the last call's provider and duration against both entries.
Its other reader, the tool trace, covers the tool rather than one call of
it and takes the last call's meta -- the only one it had before.
The occurrence selector moves to models.model so the reader that builds
the log and the reader that replays history share one definition. Its
behaviour is unchanged.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
