fix(js/plugins/googleai,vertexai): support thoughtSignature in fromGeminiPart

[yeonjaee]

Fixes #3920

Problem

When using the Gemini 3 Pro model (e.g., gemini-3-pro-preview) which enables thinking by default, the API returns response parts containing a thoughtSignature property. The current fromGeminiPart implementation in both googleai and vertexai plugins throws an Unsupported GeminiPart type error because it does not recognize parts that contain thoughtSignature without the thought property.

Solution

This PR updates the fromGeminiPart logic in both plugins to correctly identify and handle thoughtSignature parts by checking for both 'thought' in part and 'thoughtSignature' in part. This allows these parts to be processed by the existing fromThought / fromGeminiThought functions, which already support the thoughtSignature property.

Checklist:

• PR title is following https://www.conventionalcommits.org/en/v1.0.0/
• Tested (Manually verified with gemini-3-pro-preview - error resolved, responses with thoughtSignature now parse correctly)
• Docs updated (N/A - internal fix, no API changes)

[MichaelDoyle]

Thanks! I’m not totally surprised, but this does seem a little bit curious. Do you have a trace where this happened?

[yeonjaee]

Thanks! I’m not totally surprised, but this does seem a little bit curious. Do you have a trace where this happened?

Thanks for looking into this!

The legacy plugins (@genkit-ai/googleai, @genkit-ai/vertexai) currently have a known issue with the global endpoint (see #3651), so I had to patch things locally to build and test.

The issue manifests specifically in the generate trace path, and i think providing an exact trace isn’t appropriate here since reproducing it requires additional code changes to address that separate global-endpoint issue.

---

I understand and agree with the project’s direction toward @genkit-ai/google-genai as the intended replacement, and I appreciate the clarification from the maintainer.

That said, while the legacy plugins are labeled as such, they are still being released and actively used. In that context, I think closing issues solely by pointing to the replacement, rather than adding guardrails or safer failure modes for existing users of the legacy plugins, can be rough from a developer experience standpoint.

Since the maintainer has closed the issue #3920 and confirmed that @genkit-ai/google-genai fully resolves this, I’m fine with this PR being closed as well — whether by me or by the maintainers — and I’ll go ahead and close it on my side. That said, if there’s still interest in adding guardrails for legacy plugin users in the future, I’d be happy to revisit this.

[MichaelDoyle]

@yeonjaee sorry for the rough experience. Is there something that would prevent you from switching over to the new plugin? Or more of an issue in communication?

I'm on the Firebase/Google team as well. I'll relay this to the others.

[yeonjaee]

@MichaelDoyle
Thanks for the follow-up, and I appreciate you'll relay this internally.

There’s nothing fundamentally preventing me from switching — and I’m not opposed to the direction. My hesitation is simply based on my own experience that switching plugins isn’t always a trivial response to a bug, especially when reproducing or validating behavior across integrations.

So for me it’s less about communication, and more about the friction I experienced when trying to diagnose the issue.

Thanks again for taking this seriously.

[MichaelDoyle]

Of course. I understand completely. The new plugin has been out for a while now, so it’s definitely on us if folks didn’t get the message to switch much earlier. That’s really what I mean by communication. The SDK that underpins the googleai and vertexai plugins is no longer being updated, so it won’t be possible to fix forward for issues like this now or in the future.

…

On Tue, Dec 23, 2025 at 8:44 PM YeonJae Sung ***@***.***> wrote: *yeonjaee* left a comment (firebase/genkit#3921) <#3921 (comment)> @MichaelDoyle <https://github.com/MichaelDoyle> Thanks for the follow-up, and I appreciate you'll relay this internally. There’s nothing fundamentally preventing me from switching — and I’m not opposed to the direction. My hesitation is simply based on my own experience that switching plugins isn’t always a trivial response to a bug, especially when reproducing or validating behavior across integrations. So for me it’s less about communication, and more about the friction I experienced when trying to diagnose the issue. Thanks again for taking this seriously. — Reply to this email directly, view it on GitHub <#3921 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVZ2URE3MVBJTFT27GQMYT4DHVYBAVCNFSM6AAAAACOWNWP2OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMOBYGM3TGNJZHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>