fix(google): fail closed on MALFORMED_FUNCTION_CALL without a call part

[DevMello]

Summary

When Gemini ends a turn with finishReason MALFORMED_FUNCTION_CALL, the malformed call is usually dropped upstream and never arrives as a functionCall part. The fail-closed guard only fired when a call part had been emitted, so the common case surfaced as a clean empty completion and the client treated the turn as answered. The guard now fails closed on MALFORMED_FUNCTION_CALL even with zero started calls, on both the stream and non-stream paths. MAX_TOKENS with no started call keeps its plain token-limit stop, and ai-studio mode is unchanged.

Verification

• Three new tests in tests/google-vertex-stream.test.ts: the helper distinction, and the no-call-part malformed case erroring on both the stream and non-stream paths.
• Repro harness: an empty malformed turn previously bridged to response.completed with empty output, now response.failed with the truncation error. The existing MAX_TOKENS-without-call test stays green.
• bun run test, typecheck, lint:gui, privacy:scan.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed.
• Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults.

Summary by CodeRabbit

• Bug Fixes

  • Improved handling of incomplete Google responses involving malformed tool calls.
  • Responses that end unexpectedly now correctly report an error instead of appearing successfully completed.
  • Token-limit responses without started tool calls continue to be handled normally.

• Tests

  • Added coverage for streaming and non-streaming truncation scenarios.

[coderabbitai]

📝 Walkthrough

Walkthrough

Google Vertex truncation handling now uses a shared classifier. MALFORMED_FUNCTION_CALL results fail even without emitted tool calls, while zero-tool-call MAX_TOKENS results remain successful.

Changes

Google Vertex truncation handling

Layer / File(s)	Summary
Truncation classification and adapter wiring src/adapters/google-truncation.ts, src/adapters/google.ts	Added isVertexTruncatedTurn and applied it to streaming and non-streaming response parsing.
Classification and response regression coverage tests/google-vertex-stream.test.ts	Added coverage for malformed function calls, token limits, normal stops, undefined reasons, and terminal errors without emitted tool calls.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Suggested reviewers: lidge-j, ingwannu, wibias

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: failing closed on MALFORMED_FUNCTION_CALL responses without an emitted function-call part.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[lidge-jun]

Carried onto the review stack as #953 (stack 3/3), unmodified.

Your commits were taken with git cherry-pick -x, so they keep your authorship — git log --format='%an' on the stack branch shows you, not me. No content was changed; the diff on the stack is byte-identical to what you wrote here, and it applied to dev with no conflict resolution.

Verified on the stack: bun x tsc --noEmit exit 0, and the full suite at 7691 pass / 8 skip / 0 fail across 507 files.

This PR stays open until #953 lands. If a maintainer prefers to take yours directly instead, that path is unaffected — the stack commits get dropped and this one merges. Once #953 merges I'll close this as carried, with the credit already in the commit history rather than in a comment.

Stack: #951 (plan, base dev) → #952 (#908 long-context pricing) → #953 (this carry). Review bottom-up.

Thanks for the fix.

[Wibias]

Leave it as draft. Thanks. It doesnt need any more changes as you can see in juns comment on which you didn't respond to.

[lidge-jun]

Closing this as carried into #953, not as rejected. Your fix is shipping — this is bookkeeping so the same change isn't sitting in the review queue twice.

Your commit(s) are on the stack branch as 6dbd9723c, cherry-picked with git cherry-pick -x. Authorship is preserved, so git log --format='%an' shows you rather than me, and I verified the carried diff is byte-identical to yours rather than assuming it:

$ git show <yours> | git patch-id --stable
$ git show <carried> | git patch-id --stable
IDENTICAL

No content was changed and no conflict resolution was needed.

One thing I want to be straight about: my earlier comment said I'd close this after #953 merged, and I'm closing it before. #953 is open and reviewable now, so closing early is my call as maintainer to keep the queue honest — not a signal that the review finished. If the stack doesn't land, reopening this is one click, and the branch is untouched.

Verified on the stack: bun x tsc --noEmit exit 0, full suite 7729 pass / 8 skip / 0 fail across 508 files.

Stack: #951 (plan, base dev) → #952 → #953 (this carry) → #954 → #955. Review bottom-up.

Thanks @DevMello — this was a clean fix and it's in.