Both spellings of a tool call's id are read
A buffer written from a raw provider payload spells the id differently from one written by the buffer itself. Reading only one spelling makes every guard blind to the other.
The rule
- Where an assistant turn declares tool calls, a call's id is read under either the normalized spelling or the provider-flat spelling, whichever is present.
- Deduplication, dangling-call detection and id recording all read the id through the same single definition, so the three cannot disagree about which calls a turn declares.
What it means
A tool call's id can arrive spelled two ways: the shape this buffer writes itself, and the flat shape a provider payload carries straight through. Both name the same call. The rule that bites is that every reader of that id — whether it is checking for a duplicate, looking for a call nobody answered, or recording what a turn declared — has to accept either spelling, because a buffer built from raw provider turns and one built by appending through this node can end up sitting side by side in the same conversation.
A checker that only recognises its own spelling does not fail loudly. It simply stops seeing calls written the other way, so a call already answered looks unanswered, or a duplicate looks new.
Example
An assistant turn declares a call in the flat spelling a provider payload uses, and the turn that follows does not answer it.
{"role": "assistant", "content": "", "metadata": {"tool_calls": [{"id": "call_1", "name": "search"}]}}{"role": "tool", "metadata": {"tool_call_id": "call_1", "healed": true}}The placeholder carries the normalized spelling, tool_call_id, but the id it
names, call_1, came from reading the declaring turn's flat id — the same
call the normalized spelling would have named tool_call_id.