fix: preserve Vertex AI function call IDs

[gustafvh]

Link to Issue or Description of Change

• Closes: Vertex AI session service drops FunctionCall.ID and FunctionResponse.ID during deserialization, causing rearrangeEventsForFunctionResponsesInHistory to silently drop events #679

Problem

aiplatformToGenaiContent writes Vertex AI session events back into genai.Content, but currently drops FunctionCall.Id and FunctionResponse.Id during deserialization.

The write path in createAiplatformpbContent already stores those IDs, so this creates an asymmetric round trip: function call and response IDs are persisted to Vertex AI sessions, then lost when the session history is read back. Without IDs, later history processing can no longer reliably match tool calls and responses across invocations.

Solution

Set genai.FunctionCall.ID from aiplatformpb.FunctionCall.Id and genai.FunctionResponse.ID from aiplatformpb.FunctionResponse.Id when converting Vertex AI session events back to genai content.

Testing Plan

• Added TestAiplatformToGenaiContentPreservesFunctionIDs verifying IDs are preserved when deserializing Vertex AI session events.
• Ran focused unit tests locally.

go test ./session/vertexai

Alignment with adk-python

This preserves the same tool-call / tool-response pairing invariant expected across ADK implementations: persisted session history must retain function IDs so later turns can associate responses with their calls.

[gemini-code-assist]

Code Review

This pull request updates the aiplatformToGenaiContent function in the Vertex AI client to ensure that function call and response IDs are correctly mapped and preserved during conversion. Additionally, a new test case has been added to verify this behavior. I have no feedback to provide.

[radhus]

@mazas-google tagging you here

[indurireddy-TF]

Hi @gustafvh @radhus Can you please resolve merge conflicts?

[radhus]

Hi @gustafvh @radhus Can you please resolve merge conflicts?

Hi @indurireddy-TF , we're keeping all our fixes rebased on the latest release of adk-go (e.g. fork branch here). We're not keeping them rebased on every latest main commit.

We can rebase individual PRs if that brings them closer to be resolved. Is this one ready to be reviewed for merging now?

[indurireddy-TF]

Hi @gustafvh @radhus Can you please resolve merge conflicts?

Hi @indurireddy-TF , we're keeping all our fixes rebased on the latest release of adk-go (e.g. fork branch here). We're not keeping them rebased on every latest main commit.

We can rebase individual PRs if that brings them closer to be resolved. Is this one ready to be reviewed for merging now?

yes

[radhus]

@indurireddy-TF rebased 👍

[foxfrikses]

Thank you for the fix!