fix: prevent warnings and skip-validator injection for valid Gemini 3 parallel function calls - #17649
Conversation
Bugfix reviewOutcome: changes-required Reproduction replayStatus: no-longer-reproduces The exact original reproduction completed successfully and the original bug signal did not appear. Fixes issueStatus: partially-addresses The fix handles the reproduced consecutive standard function calls, but its batch boundaries do not fully match Google's per-model-response semantics. Google specifies that only the first functionCall in a parallel response carries the signature. Concerns:
Side effectsRisk: medium A signed built-in server tool call can cause a subsequent unsigned custom functionCall to be emitted without the existing fallback sentinel or warning. Google permits toolCall, toolResponse, and functionCall parts to coexist and requires their signature context to be preserved. Concerns:
PerformanceRisk: none The implementation adds one message-local boolean and constant-time checks per content part, with no meaningful memory or runtime cost. Backwards compatibilityRisk: medium Stored data is not mutated, but replaying existing mixed built-in/custom histories may now omit the fallback sentinel where missing custom-function metadata previously received mitigation. Concerns:
ArchitectureRisk: medium The change is correctly localized to the Google provider, but it conflates the SDK's normalized tool-call type with Google's distinct functionCall and server toolCall wire concepts. Concerns:
Change scopeStatus: minimal The tracked diff is limited to the converter, focused regression tests, and the required patch changeset; no unrelated tracked changes were found. SecurityRisk: none The change introduces no new parsing, network access, credential handling, or externally controlled execution path. TestingStatus: needs-more The added tests cover consecutive ordinary calls and the implemented reset, but omit mixed built-in/custom tool responses and encode a questionable non-tool boundary assumption. Concerns:
VerificationInspected every tracked diff hunk and the response-message construction path, confirmed the package type-check, Node test suite, and Edge test suite pass, and ran a focused mixed server/custom converter probe that exposed the untested suppression case. Relevant Documentation
|
lgrammel
changed the title
|
Addressed PR comment 5036567100.
Updated the tracking boundary to the full assistant/model response and restricted it to standard |
Bugfix reviewOutcome: approved Reproduction replayStatus: no-longer-reproduces The exact original reproduction completed successfully and the original bug signal did not appear. Fixes issueStatus: fully-addresses The converter now recognizes unsigned standard function calls following a signed standard function call in the same model response as valid Gemini 3 parallel calls, while preserving mitigation for genuinely missing first signatures. Side effectsRisk: low State is scoped to each assistant response and only signed standard function calls seed it; text and server-tool parts preserve the response boundary without incorrectly suppressing mitigation. PerformanceRisk: none The implementation adds one response-local boolean and constant-time checks while processing existing content parts, with no material memory or runtime cost. Backwards compatibilityRisk: low Stored messages are not modified; replay serialization changes only by omitting unnecessary mitigation for valid signed-first parallel function-call responses. ArchitectureRisk: none The provider-specific behavior remains localized in the Google message converter, distinguishes standard function calls from built-in server calls, and introduces no new dependencies, exports, or cross-package source access. Change scopeStatus: minimal The tracked changes are limited to the Google converter, focused regression tests, and the required patch changeset. SecurityRisk: none The change introduces no new parsing, network, credential, URL-handling, or execution paths. TestingStatus: appropriate Regression tests cover signed-first parallel calls, intervening text and server parts, server calls not seeding function-call state, missing-signature fallback, non-Gemini behavior, and provider namespaces. VerificationInspected every tracked diff hunk and the response-message construction path. The full Google Node and Edge suites each passed 700 tests, full workspace type checking passed, focused lint and formatting checks passed, and the diff had no whitespace errors. Relevant Documentation |
…emini 3 parallel function calls (#17745) ## Background Gemini 3 legitimately signs only the first standard function call in a parallel model response, but replaying later unsigned calls caused misleading warnings and unnecessary skip-validator injection. ## Root Cause The Google converter evaluated missing signatures per normalized tool-call part rather than recognizing that one assistant message represents a model response whose first standard parallel function call carries the shared signature. ## Summary The converter now tracks signed standard function calls across the entire assistant response, preserves state across mixed parts, excludes built-in server calls from seeding that state, retains fallback mitigation for genuinely missing signatures, and includes a patch changeset. ## Testing Regression coverage verifies three-call parallel responses, intervening text and server parts, signed-server/unsigned-function behavior, genuine missing-signature fallback, and provider namespace handling. Google Node and Edge suites, full workspace type checking, and focused formatting/lint checks pass. ## End-to-end Validation - `pnpm -C packages/google build && pnpm -C examples/ai-functions exec tsx src/stream-text/google/function-call-id.ts` — live Gemini calls produced three parallel tool calls and completed replay with final text. - `pnpm -C examples/ai-functions exec tsx -e '<inline Gemini 3.5 Flash parallel-call probe>'` — observed `[signed,unsigned,unsigned]`, an empty warnings array, and successful final text generation. ## Related Issues Fixes #16298 Closes #17620 Backport of #17649 Co-authored-by: mttzzz <16290052+mttzzz@users.noreply.github.com> Co-authored-by: lgrammel <205036+lgrammel@users.noreply.github.com>
|
🚀 Published in:
|
1 participant
Background
Gemini 3 legitimately signs only the first standard function call in a parallel model response, but replaying later unsigned calls caused misleading warnings and unnecessary skip-validator injection.
Root Cause
The Google converter evaluated missing signatures per normalized tool-call part rather than recognizing that one assistant message represents a model response whose first standard parallel function call carries the shared signature.
Summary
The converter now tracks signed standard function calls across the entire assistant response, preserves state across mixed parts, excludes built-in server calls from seeding that state, retains fallback mitigation for genuinely missing signatures, and includes a patch changeset.
Testing
Regression coverage verifies three-call parallel responses, intervening text and server parts, signed-server/unsigned-function behavior, genuine missing-signature fallback, and provider namespace handling. Google Node and Edge suites, full workspace type checking, and focused formatting/lint checks pass.
End-to-end Validation
pnpm -C packages/google build && pnpm -C examples/ai-functions exec tsx src/stream-text/google/function-call-id.ts— live Gemini calls produced three parallel tool calls and completed replay with final text.pnpm -C examples/ai-functions exec tsx -e '<inline Gemini 3.5 Flash parallel-call probe>'— observed[signed,unsigned,unsigned], an empty warnings array, and successful final text generation.Related Issues
Fixes #16298
Closes #17620
Co-authored-by: mttzzz 16290052+mttzzz@users.noreply.github.com
Co-authored-by: lgrammel 205036+lgrammel@users.noreply.github.com