[Gemini 3 Flash Preview] Inconsistent thought_signature generation in parallel function calls causes 400 errors

[peterbherman]

Is this a client library issue or a product issue?

This is a PRODUCT ISSUE (Gemini 3 Flash Preview API behavior), not a client library issue. The client library is working correctly - we've verified this with extensive debug logging showing the raw API responses. However, filing here as the Gemini API is the underlying product for this SDK.

---

Environment details

• Programming language: TypeScript/JavaScript (Node.js)
• OS: Linux
• Language runtime version: Node.js (via Vertex AI)
• Package version: @google/genai v1.38.0
• Model: gemini-3-flash-preview
• API: Vertex AI
• Region: global

---

Steps to reproduce

Summary

Gemini 3 Flash Preview inconsistently generates thought_signature fields for parallel function calls. When 3+ tools are called, only the first 1-2 receive signatures, causing subsequent 400 INVALID_ARGUMENT errors when returning function results.

Reproduction Steps

1. Configure Vertex AI with gemini-3-flash-preview model (global region)
2. Define 3 or more function/tool declarations
3. Send a prompt that triggers 3+ parallel function calls via generateContentStream
4. Capture raw API response - observe only first 1-2 tool calls have thought_signature field
5. Return all function results (with signatures where provided)
6. Result: 400 INVALID_ARGUMENT error: "Unable to submit request because function call <name> in the X. content block is missing a thought_signature"

---

Evidence

Test Case 1: User request requiring 3 data operations

Google's Raw Response (3 parallel tool calls):

{
  "toolCalls": [
    {
      "toolName": "get_resource_list",
      "hasThoughtSignatureField": true,
      "thoughtSignatureValue": "CiEBjz1rX0ilumvPg6k0sMMUtISoQCLJv2bPJ7Vv9r+Xw0o=",
      "thoughtSignatureLength": 48
    },
    {
      "toolName": "get_detailed_results", 
      "hasThoughtSignatureField": true,
      "thoughtSignatureValue": "CiEBjz1rX0ilumvPg6k0sMMUtISoQCLJv2bPJ7Vv9r+Xw0o=",
      "thoughtSignatureLength": 48
    },
    {
      "toolName": "analyze_data",
      "hasThoughtSignatureField": false,
      "thoughtSignatureValue": undefined
    }
  ]
}

Result: ✅ Position 1-2 have signatures | ❌ Position 3 missing → 400 error

Error:

Unable to submit request because function call `analyze_data` 
in the 6. content block is missing a `thought_signature`.

---

Test Case 2: Different prompt, same 3 tools

Google's Raw Response:

{
  "toolCalls": [
    {
      "toolName": "analyze_data",
      "hasThoughtSignatureField": true,
      "thoughtSignatureValue": "CiEBjz1rX0ilumvPg6k0sMMUtISoQCLJv2bPJ7Vv9r+Xw0o=",
      "thoughtSignatureLength": 48
    },
    {
      "toolName": "get_detailed_results",
      "hasThoughtSignatureField": false,
      "thoughtSignatureValue": undefined
    },
    {
      "toolName": "get_resource_list",
      "hasThoughtSignatureField": false,
      "thoughtSignatureValue": undefined
    }
  ]
}

Result: ✅ Position 1 has signature | ❌ Position 2-3 missing → 400 error

---

Key Finding: Position-Based Bug

The tool get_resource_list:

• ✅ HAD signature in Test Case 1 (position 1)
• ❌ NO signature in Test Case 2 (position 3)

This proves it's position-based, not tool-specific.

---

Pattern Summary

Test	Total Tools	Signatures Provided	Failed On
1	3	Position 1-2 only	Position 3
2	3	Position 1 only	Position 2

Gemini 3 Flash generates signatures for ~first 1-2 tool calls, then stops. The cutoff is non-deterministic.

---

Debug Logs

Raw logs from production showing API response directly from SDK:

[llm] 2026-01-23 16:19:40 [debug]: [RAW GOOGLE RESPONSE] Tool call received
{"toolName":"analyze_data","hasThoughtSignatureField":true,
 "thoughtSignatureValue":"CiEBjz1rX0ilumvPg6k0sMMUtISoQCLJv2bPJ7Vv9r+Xw0o="}

[llm] 2026-01-23 16:19:40 [debug]: [RAW GOOGLE RESPONSE] Tool call received
{"toolName":"get_detailed_results","hasThoughtSignatureField":false}

[llm] 2026-01-23 16:19:41 [debug]: [RAW GOOGLE RESPONSE] Tool call received
{"toolName":"get_resource_list","hasThoughtSignatureField":false}

---

Implementation Verification

We've ruled out client library issues by:

✅ Capturing thought signatures from streaming responses correctly
✅ Preserving signatures through tool execution lifecycle
✅ Returning signatures byte-for-byte to the API
✅ Extensive debug logging at every step
✅ Confirming with raw API response logs that Google doesn't send all signatures

The same implementation works flawlessly with gemini-2.5-flash, proving this is a Gemini 3 API issue.

---

Impact

• Severity: Critical - prevents production use with multi-tool scenarios
• Scope: Any application using Gemini 3 Flash with 3+ parallel function calls
• Frequency: Consistent when 3+ tools called
• Reliability: Non-deterministic cutoff makes failures unpredictable

---

Workaround

Use gemini-2.5-flash - it doesn't use thought signatures and handles parallel function calls reliably.

---

Questions

1. Why are thought signatures inconsistently generated for parallel function calls?
2. Is this a known limitation of the preview API?
3. What is the intended maximum number of parallel function calls with thought signatures?
4. Is there a timeline for fixing this?
5. Should Gemini 3 Flash be considered production-ready for function calling?

---

Additional Context

We have extensive debug logs, raw API responses, and reproduction code available. Happy to provide additional evidence or collaborate on debugging.

This bug makes Gemini 3 Flash unsuitable for production use with multi-tool function calling.

[Varun-S10]

Hi @peterbherman, I was able to reproduce the issue. I have observed that the thought_signature field is sometimes undefined. I'm escalating this to the team.

[peterbherman]

Thanks @Varun-S10!

[olivier-lacroix]

@Varun-S10 do you have any visibility on resolution or workaround? this makes working with Gemini 3 Flash preview quite impossible in an agentic workflow.

[Colum]

Same here, any timeline on this fix?

[peterbherman]

Update

Haven't had time to look at this for a bit, but I now believe this issue is working as intended per Google's spec, and the 400 errors I was seeing had a client-side root cause.

Google's docs (thought-signatures) state that for parallel function calls, only the first call in a response receives a thought_signature; subsequent parallel calls correctly have no signature. That matches what @Varun-S10 and I both saw when we reproduced.

The 400 errors come from client-side history reconstruction. If you extract each functionCall into its own stored message and re-emit them as separate Content entries with role: "model", Gemini treats each one as a new "step" — and the spec requires the first functionCall of each step to have a signature. So call #2 fails validation.

The Fix

When the model returns N parallel calls in a single response, group them back into one Content with N parts when sending history on the next turn. Only one signature is needed, because it's one step. I was able to use a parallelGroupId stamp at capture time + merge-at-reconstruction logic.

If you're using the SDK's built-in chat feature or appending the full model response object directly to history, this is handled for you. ⚠️ 👉 If you're manually extracting parts (like we were), you need this grouping yourself.

Example psuedocode:

// === At capture time (when Gemini's response streams in) ===
// Generate ONE groupId per response if it contains multiple functionCalls.
// Stamp the groupId on every stored representation of those calls.

const parallelGroupId = responseFunctionCalls.length > 1
  ? uuid()
  : undefined;

for (const fc of responseFunctionCalls) {
  storedMessages.push({
    role: "model",
    functionCall: { name: fc.name, args: fc.args },
    thoughtSignature: fc.thoughtSignature,  // only set on the first; undefined on the rest
    parallelGroupId,                         // same id for every call from this response
  });
}

// === At history-reconstruction time (building the next request's contents[]) ===
// Collapse consecutive stored-model-messages that share a parallelGroupId
// into ONE Content with multiple parts — so Gemini sees one step, not N.

function reconstructContents(storedMessages) {
  const contents = [];
  let i = 0;
  while (i < storedMessages.length) {
    const m = storedMessages[i];
    if (m.role === "model" && m.functionCall) {
      // Collect this message and any adjacent ones with the same group.
      const group = [m];
      while (
        i + 1 < storedMessages.length &&
        storedMessages[i + 1].parallelGroupId !== undefined &&
        storedMessages[i + 1].parallelGroupId === m.parallelGroupId
      ) {
        i++;
        group.push(storedMessages[i]);
      }
      contents.push({
        role: "model",
        parts: group.map(g => ({
          functionCall: g.functionCall,
          thoughtSignature: g.thoughtSignature,  // only the first will carry one
        })),
      });
      // Don't forget: collapse the matching functionResponse messages into
      // a single `role: "user"` content with N parts the same way.
    } else {
      contents.push(m);
    }
    i++;
  }
  return contents;
}

// Now Gemini receives:
//   { role: "model", parts: [fc1+sig, fc2, fc3] }        ← one step, one sig, valid
// Instead of:
//   { role: "model", parts: [fc1+sig] },
//   { role: "model", parts: [fc2] },   ← "first call of step 2 needs a signature" → 400
//   { role: "model", parts: [fc3] },

Also: my Test Case 1 above showed two identical signature strings on positions 1 and 2 — those were a logging artifact on my end, not actual Google behavior. Only Test Case 2's one-signature-at-position-1 pattern is accurate. Felt I owed this issue thread that correction.