2 Commits
Author SHA1 Message Date
Justin Truong d13cc0804a fix(providers): carry tool name on tool results for Gemini
Gemini drops tool_call_id and pairs functionCall/functionResponse by
function name, so its OpenAI-compat shim requires a non-empty
FunctionResponse.name. The name was only recoverable through a reverse
id->name lookup over assistant tool_calls still present in the request
window, which fails after pruning, truncation or tool_call collapse and
produces HTTP 400 "Name cannot be empty" on any follow-up iteration.

Add Message.ToolName, set it at every tool-result creation site and
preserve it through context pruning, then prefer it when serializing.
Fall back to the existing index for history persisted before the field,
so old sessions keep working without a reset.

When neither source resolves a name, drop the unlabelled tool result
instead of emitting an empty one: an empty name is a guaranteed 400 and
a synthetic name would match no prior functionCall. Gated behind the
existing Gemini detection so other OpenAI-compat hosts, which pair by
tool_call_id, are unaffected.

Field is JSON-optional, so session history needs no migration and older
binaries ignore it on rollback.
2026-08-03 22:50:06 +07:00
viettranx 7773fa01b8 test(providers/openai): failing tests for tool msg name field (Gemini 400 repro)
Reproduces trace 019d8f33-2de1-7ab2-9a32-9df92cd610dd where Google's
OpenAI-compat shim returns 400 'Name cannot be empty' on FunctionResponse
because role=tool wire messages omit the 'name' field.

- TestBuildRequestBody_ToolMessageIncludesName: expects 'name' on tool msg
- TestBuildRequestBody_ToolMessageNameLookupUsesRawID: long ToolCallID still resolves
- TestBuildRequestBody_ToolMessageWithoutMatchingCallOmitsName: orphan stays nameless
2026-04-15 12:33:08 +07:00