chore(examples): reproduction scripts for Gemini 3 thoughtSignature issues

[gr2m]

Summary

Adds three reproduction scripts under examples/ai-functions/src/stream-text/gateway/ covering the active thought_signature issues against google/gemini-3-flash on release-v6.0. Each script targets one specific claim from the issue tracker; together they map out where the bug is and is not.

File	Issue / claim targeted	Outcome on ai@6.0.190 / @ai-sdk/gateway@3.0.119 / @ai-sdk/google@3.0.79 / @ai-sdk/google-vertex@4.0.135
issue-14196.ts	#14196 — Vertex rejects Google-AI-Studio thoughtSignature on Gateway failover (order: ['google','vertex']).	Not reproduced. Turn 1 (only: ['google']) → 200 with 10 google-namespaced signatures. Turn 2 (only: ['vertex'], the failover sim) → 200; Vertex accepts the signatures. Turn 3 (reporter's exact order: ['google','vertex']) → 200 on Google, no failover triggered.
issue-10344-zod-validation.ts	#10344 (post-close, hsheth2) — "tool call fails due to zod validation" drops the signature.	Not reproduced. Forced execute() throw on the 3rd call. SDK preserves providerMetadata.google.thoughtSignature on both the tool-call and the synthetic tool-error content parts. Gemini accepts the next request, model retries, chain completes at step 7.
issue-10344-client-side-tools.ts	#10344 (post-close, pheuter) — client-side tool execution path where the application drops providerMetadata between turns.	Reproduced deterministically. Turn 2A (signature preserved) → 200. Turn 2B (signature stripped from the assistant tool-call) → HTTP 400 Function call is missing a thought_signature in functionCall parts.

What this tells us

• The SDK preserves thoughtSignature correctly on the wire — across direct provider calls, Gateway routing, mid-chain tool failures, and the Vertex/Google namespace boundary (PR fix(google): resolve thoughtSignature from vertex namespace on gateway failover #13060).
• The remaining failure mode is at the application layer: anywhere assistant tool-call parts are serialized/persisted/re-hydrated without round-tripping providerOptions (custom DB schemas, useChat server routes that rebuild messages from the client payload, synthetic tool-call injection). When that happens, the next Gemini 3 request fails with HTTP 400.
• Follow-up issue feat(provider/google): auto-inject skip_thought_signature_validator for Gemini 3 tool-call replays without a signature #15550 proposes a warning in @ai-sdk/google that fires when an outbound Gemini 3 request contains functionCall parts with no thoughtSignature under any recognised namespace — making the cause visible before the 400 hits.

How to run

Set AI_GATEWAY_API_KEY to a key whose team allows both the google and vertex providers, then from examples/ai-functions/:

pnpm tsx src/stream-text/gateway/issue-14196.ts
pnpm tsx src/stream-text/gateway/issue-10344-zod-validation.ts
pnpm tsx src/stream-text/gateway/issue-10344-client-side-tools.ts

Each script ends with a clear ✓/✗ summary. The third one is also useful as a smoke check — if Turn 2B ever starts returning 200, Google has relaxed signature validation and #10344-style failures will quietly disappear; if Turn 2A ever starts failing, the SDK is dropping signatures somewhere it shouldn't.

Refs: #10344 #11413 #14196 #15550, related fix in #13060.

Test plan

• All three scripts run cleanly with a valid AI_GATEWAY_API_KEY whose team allows google and vertex providers
• issue-14196.ts: three Gateway turns all return 200 today
• issue-10344-zod-validation.ts: chain completes despite mid-chain tool failure; signatures preserved on the error step
• issue-10344-client-side-tools.ts: Turn 2A returns 200, Turn 2B returns 400 with the expected error wording — deterministic
• Type-checks under examples/ai-functions

[gr2m]

Added a second reproduction script, examples/ai-functions/src/stream-text/gateway/issue-10344-zod-validation.ts, targeting the post-close claim on #10344 by @hsheth2:

For me this is particularly happening when the tool call fails due to zod validation. When the tool calls succeed it does seem to pass the thought_signature properly.

The script runs a sequential treasure-hunt chain on google/gemini-3-flash via the Gateway (only: ['google']) and forces execute() to throw on the 3rd tool call.

Result on ai@6.0.190 / @ai-sdk/google@3.0.79 / @ai-sdk/gateway@3.0.119: claim does not reproduce.

The step where the tool fails looks like this — both the tool-call and the synthetic tool-error carry the same thoughtSignature:

[step 2] finishReason=tool-calls toolCalls=1 toolResults=0
  tool-call  clue(mailbox)  sigPrefix=Et4BCtsBAQw5
  tool-error clue(mailbox)  errorMsg="BOOM: simulated tool failure..." sigPrefix=Et4BCtsBAQw5

The next Gemini request is accepted (no thought_signature 400), the model retries the failing call with a fresh signature, and the chain completes at step 7. So the SDK's tool-error → tool-result conversion in packages/ai/src/generate-text/to-response-messages.ts preserves the signature correctly on failed calls today.

Other post-close claims on #10344 not directly testable here:

• @pheuter (client-side tool execution edge case) — different code path; would need a separate script.
• @shtefcs (multi-agent handoff) — partially covered by the Turn 1 → Turn 2 split in issue-14196.ts, which already works.
• @benevbright — no repro details provided.

[gr2m]

Added a third reproduction script — examples/ai-functions/src/stream-text/gateway/issue-10344-client-side-tools.ts — and this one reproduces the bug deterministically.

Targets @pheuter's post-close note on #10344:

Gemini 3 models require a thoughtSignature on every functionCall part when replaying conversation history. The AI SDK normally preserves this through callProviderMetadata, but it's possible in certain edge cases for clients not to store/send it back. In our codebase, it can happen with client-side tool execution.

Setup: tool defined without execute, so the SDK does not auto-run it (client-side execution path). Turn 1 captures the assistant tool-call + its providerOptions.google.thoughtSignature. Turn 2 has two variants:

Turn	History shape	Result on ai@6.0.190 + @ai-sdk/gateway@3.0.119 + google/gemini-3-flash
2A	tool-call with providerOptions.google.thoughtSignature	✓ 200 — model produces a response
2B	tool-call without providerOptions	✗ HTTP 400 — Function call is missing a thought_signature in functionCall parts. […] Additional data, function call \default_api:weather` , position 2.`

Sample output (trimmed):

[Turn 1] tool-call 7sokhw95 input={"location":"San Francisco"} sigPrefix=Eo0DCooDAQw51sc3... (len=536)
[client] executed tool externally, result: {"location":"San Francisco","temperature":72,"condition":"sunny"}

=== Turn 2A: well-behaved client — signature preserved on tool-call ===
✓ Turn 2A (signature preserved) succeeded.

=== Turn 2B: buggy client — providerMetadata stripped from tool-call ===
✗ Turn 2B (signature stripped) FAILED:
  statusCode: 400
  message: Function call is missing a thought_signature in functionCall parts. […]

--- Summary ---
  Turn 2A (well-behaved): succeeded ✓ (expected)
  Turn 2B (signature stripped): failed with 400 ✓ — bug reproduced (expected)

Interpretation: the SDK preserves the signature on the wire and Gemini validates it. The reported thought_signature 400s are an application-layer failure mode — application code that serializes/deserializes assistant tool-call messages without round-tripping providerOptions (or callProviderMetadata in older APIs) loses the signature and the next Gemini call fails.

This narrows the issue substantially. Common surfaces where this happens:

• Persisting chat history to a database with a custom schema that drops providerMetadata
• useChat round-trips where the server route reconstructs messages from the client payload without the providerMetadata field
• Custom tool result injection (e.g. inserting a synthetic functionCall block to seed an agent state)

For surfaces 1 and 2, the fix is on the application side: preserve providerMetadata (or providerOptions) on every tool-call part across persistence and HTTP boundaries. For surface 3, Google documents "skip_thought_signature_validator" as a dummy sentinel (also noted by @pheuter upthread).

Whether the SDK should do anything to mitigate this (e.g., emit a warning when a tool-call is replayed without a signature for Gemini 3 models, or auto-inject skip_thought_signature_validator in known synthetic-injection paths) is a follow-up design question; not in scope for this PR.

[gr2m]

Filed follow-up: #15550 — proposes a Gemini-3-only runtime warning when an outbound request contains functionCall parts with no thoughtSignature under any recognised namespace. Warning only (no throw, no auto-inject); intent is to make the application-layer cause visible before the inevitable 400.