Gemini Interactions API: continuing a streamed Google Search interaction returns 400 `Tool type of tool_call part does not match with tool call context.` (fixed server-side)

Context

Source(s): https://discuss.ai.google.dev/t/gemini-interactions-http-400-on-continuation-after-streaming-google-search-v1-and-v1beta/186291 Signal: 171 views, 2 likes; staff answer accepted, and the original poster confirmed the fix (October 2026). Status: reported working by source, not reproduced by us.

Problem

A streamed interaction that actually runs the built-in google_search tool completes normally, but the next request that continues it with previous_interaction_id fails with HTTP 400, both for an ordinary follow-up user message and for a custom function_result. A non-streaming continuation from the same interaction returns the same message as a JSON error. A longer tool sequence gave the same error with contents[3].parts[0].

Error (redacted / normalized)

event: error
data: {"error":{"message":"contents[1].parts[0]: Tool type of tool_call part does not match with tool call context.","code":"invalid_request"},"event_type":"error"}

Applies when

gemini-3.8-flash, Gemini Interactions API over direct REST (/v1/interactions and /v1beta/interactions), reproduced in Postman without any SDK; a commenter saw the same with URL Context and File Search.

Confirm it is this problem

1. Start an interaction with "stream": true and "tools": [{"type": "google_search"}], and check that google_search_call and google_search_result actually appear. → expect: interaction.completed with status completed.
2. Send a follow-up with previous_interaction_id set to that interaction's id. → expect (before the fix): the 400 above. In the original poster's control tests, the same flow with a non-streaming first request succeeded.

Not this when / boundary

The first interaction was not streamed, or never actually ran a tool; then a 400 has another cause (our inference). For GET /v1beta/interactions/{id} returning Multiple authentication credentials received, see fix/124.

Root cause

A commenter compared the logs and found that streamed google_search_call events were missing "search_type": "web_search", which the non-streamed version included. Staff thanked them for spotting it and then rolled out a fix; staff did not state the root cause in other words.

Fix

1. No client change: staff said on October 8, 2026 that a fix is in production, and that both newly streamed Google Search interactions and previously stored ones should now continue cleanly via previous_interaction_id. Retry the continuation request. → expect: the original poster replied "The update seems to work for us."
2. If you added a workaround while it was broken (for example a non-streaming first request, or falling back to generateContent), you can test removing it (our inference).

How to verify

The follow-up request after a streamed Google Search interaction returns a normal response instead of HTTP 400.

What did not work

Re-sending the previous interaction's tools and values in the next request still gave the 400 (a commenter).

Risks

Don't paste your API key into shared Postman collections or forum posts (our inference); the original poster used YOUR_API_KEY as a placeholder.

Verified scope

Gemini Interactions API with `gemini-3.8-flash`, late September to October 8, 2026.

Becomes obsolete when

Already fixed server-side; keep only as a reference for the error text.