fix issue with tool calling using gemini 3.0 pro perview

[lukemilby]

issue where gemini 3.0 pro preview would error because google's thought_signature was missing

response I would get

Error processing message: LLM call failed after retries: API request failed:
  Status: 400
  Body:   [{
  "error": {
    "code": 400,
    "message": "Function call is missing a thought_signature in functionCall parts. This is required for tools to work correctly, and missing thought_signature may lead to degraded model performance. Additional data, function call default_api:read_file , position 20. Please refer to https://ai.google.dev/gemini-api/docs/thought-signatures for more details.",
    "status": "INVALID_ARGUMENT"
  }
}

[Leeaandrob]

@Zepan Fixes tool calling with Gemini 3.0 Pro Preview. Gemini is a popular provider and tool calling is a core feature.

Recommendation: Merge. +47/-16, targeted fix for a widely-used provider.

[mrbeandev]

Related update: PR #343 includes additional fixes around Gemini/Antigravity tool-calling reliability and has been tested end-to-end.

Link: #343

[nikolasdehor]

Good fix for a real breakage with Gemini 3.0 Pro thinking mode. The thought_signature round-trip is necessary per Google's docs — without it, the API returns 400 on subsequent tool call requests.

Suggestions (non-blocking):

1. Duplicate types: ExtraContent / GoogleExtraContent are defined identically in both pkg/providers/types.go and pkg/tools/types.go. Consider defining once and importing to avoid drift.

2. Future-proofing: Consider using json.RawMessage for extra_content to generically round-trip any provider's extra fields without needing struct changes per vendor.

3. Tests: This is a critical code path — a unit test parsing a sample Gemini response with thought_signature and verifying round-trip would prevent regressions.

LGTM — approving as the fix is correct and urgent.

[nikolasdehor]

Good fix for Gemini 3.0 Pro thought_signature requirement. The approach of passing ExtraContent through the ToolCall chain is correct.

A few observations:

1. Duplicated types: ExtraContent and GoogleExtraContent are defined in both pkg/providers/types.go and pkg/tools/types.go. This is a maintenance risk -- if Google adds more fields, you need to update both. Consider having one package import from the other, or defining a shared types package.

2. Hardcoded to Google: The ExtraContent struct only has a Google field. If other providers adopt similar patterns, you would need to keep adding top-level fields. An alternative approach would be map[string]interface{} for ExtraContent to make it provider-agnostic, though the struct approach is safer for type-checking.

3. No tests: This PR lacks unit tests for the thought_signature roundtrip. A test that verifies parseResponse correctly extracts thought_signature from a Gemini response and that it survives through to assistantMsg.ToolCalls would increase confidence.

4. Forward compatibility: If Google adds new required fields, the current approach requires a code change each time. Worth considering a more flexible ExtraContent representation for future iterations.

Overall, this addresses a real issue blocking Gemini 3.0 Pro users. The approach is reasonable.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sipeed-bot]

@lukemilby Hi! This Gemini tool calling fix has had no activity for over 2 weeks, so I'm closing it to keep things tidy. Feel free to reopen anytime if it's still relevant.