fix: strip embedded thought signature from LiteLLM tool call ids

[benclarkeio]

Fixes #6742

Problem

LiteLLM embeds a Gemini thought_signature inside the tool call id, separated by __thought__ (see _THOUGHT_SIGNATURE_SEPARATOR). _message_to_generate_content_response already extracts that signature onto part.thought_signature, but then assigns the raw id to the function call:

thought_signature = _extract_thought_signature_from_tool_call(tool_call)
part = types.Part.from_function_call(...)
function_call.id = tool_call.id      # still "call_abc__thought__AY89a18..."
if thought_signature:
    part.thought_signature = thought_signature

So every consumer of function_call_id gets several hundred characters of base64 glued onto the real id:

call_abc__thought__AY89a18qpllj6mkpxPjhFEcbBbtEsqy4Ia4Eam2lD_NsoZ...

It leaks into logs, into any UI that displays a tool call id, and into anything that derives a name from one.

Fix

Split the separator off before assigning the id. The signature is already preserved on the part, so nothing is lost.

Why the round trip still works

• _content_to_message_param re-attaches the signature to the outgoing tool call from part.thought_signature, via both provider_specific_fields and extra_content.google.thought_signature.
• _extract_thought_signature_from_tool_call checks those two locations before falling back to the id-embedded form, which exists only for providers that drop the other channels.
• Both sides of the call/response pairing (the assistant tool_calls entry and the tool message's tool_call_id) are generated from ADK's own stored parts, so stripping consistently keeps them matched.

Testing

Added test_message_to_generate_content_response_strips_signature_from_id, asserting the id is split and the signature still lands on the part. tests/unittests/models/test_litellm.py passes in full (387 passed). Formatted with pyink per the repo config.

Note

This replaces #6599, which was opened from the same work but carried a co-author trailer on its commit. Rebased onto current main (the surrounding code now goes through a local function_call variable) and reopened clean.

[varunbiluri]

The ID should only be shortened when the suffix was actually accepted as the embedded thought signature. As written, every provider-issued ID containing __thought__ is truncated, even when _decode_thought_signature() rejects the suffix (or when the signature was sourced from extra_content / provider_specific_fields). Tool-call IDs are otherwise opaque, so an ID such as job__thought__not-base64 becomes job, which can break response pairing or collide with another call. Please have the extraction path return the cleaned ID only when it successfully decodes the ID-embedded form (or otherwise gate this assignment on successful decoding specifically from that fallback), and add coverage showing a non-signature ID containing the separator is preserved.

[benclarkeio]

Good catch — pushed in 86dfed1.

The split is now gated on the same decode the extraction path uses: partition on the separator, keep the head only when the suffix decodes as a signature, otherwise leave the id exactly as the provider sent it. So job__thought__not-base64 survives whole, and so does an id that happens to contain the separator when the signature actually arrived via extra_content / provider_specific_fields.

I kept the gate at the assignment rather than changing what _extract_thought_signature_from_tool_call returns. It has one caller and the id is rewritten in exactly one place, so this gives the same guarantee without widening the helper's contract — it stays a signature extractor.

Tests added:

• a non-signature id containing the separator is preserved
• an id containing the separator is preserved when the signature came from extra_content
• the embedded case still round-trips: cleaned inbound, signature re-attached to the outgoing tool call in both provider_specific_fields and extra_content
• the same case through generate_content_async, which is the path the issue reports

On pairing specifically — that one was safe either way, since both the assistant tool call and the tool message's tool_call_id are rebuilt from ADK's own stored parts, so a deterministic split stays matched. The truncation of an unverified id was the real risk, and this closes it.