Skip to content

Conversation

@CorieW
Copy link
Member

@CorieW CorieW commented Oct 27, 2025

Resolves #3443

Plugin migration guide

Notable Changes

  • Migrates from v1 to v2 API.

Testing

  • Checked that the same number of modes and embedders load.
image
  • Checked that the models load with the same names/prefixes on the UI.
image
  • Checked that the embedders load with the same names/prefixes on the UI.
image
  • Checked that at least one Gemini model works consistent with pre-migration on the UI.
image
  • Checked that at least one Imagen model works consistent with pre-migration on the UI.

  • Checked that at least one Veo model works consistent with pre-migration on the UI.
    Can't see any load in, even before migration.

  • Checked that at least one Gemma model works consistent with pre-migration on the UI.

image
  • Checked that at least one embedder works consistent with pre-migration on the UI.
image
  • Using a model object, checked using a flow works consistent with pre-migration.
image
  • Using an embedder object, checked using a flow works consistent with pre-migration.
image
  • Using a model string ('pluginName/modelName'), checked using a flow works consistent with pre-migration.
image
  • Using an embedder string ('pluginName/embedderName'), checked using a flow works consistent with pre-migration.
image
  • Using a resolved model object, checked using a flow works.
image
  • Using a resolved embedder object, checked using a flow works.
image
  • Using a model string, checked using a streaming flow works consistent with pre-migration.
image
  • Using a model object, checked using a streaming flow works consistent with pre-migration.
image
  • Using a resolved model object, checked using a streaming flow works.
image
  • Tested error response from model.
image
  • Tested error response from embedder.
image
  • Tested model media input.
image
  • Tested model tool calling.
image
  • Tested .list
image

@CorieW CorieW requested a review from cabljac October 27, 2025 11:47
@CorieW CorieW marked this pull request as draft October 27, 2025 11:57
debugTraces: options?.experimental_debugTraces,
})
actions.push(
defineGoogleAIModel({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does the original defineGoogleAIModel overwrite different version, same name? or do we get both versions registered?

Can apiVersions include both, and then do we end up with different behaviour in v2 now, where we have both actions?

Need to confirm what's going on here so we don't change expected behaviour i think

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worth double checking.

debugTraces: options?.experimental_debugTraces,
})
actions.push(
defineGoogleAIModel({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Q: does this always return an action, or can it return undefined or something?

do we need to do some kind of filtering here maybe?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It returns ModelAction, but can throw an error if API key not set

);
}
if (apiVersions.includes('v1')) {
Object.keys(SUPPORTED_GEMINI_MODELS).forEach((name) =>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on this occasion i'd actually prefer a map and spread now maybe:

actions.push(
  ...Object.keys(SUPPORTED_GEMINI_MODELS).map((name) =>
    defineGoogleAIModel({ ... })
  )
);

forEach is clean for the previous code where we're just doing side effects, but now we're actually interested in the actions returned.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree.

// If debugTraces is enable, we wrap the actual model call with a span, add raw
// API params as for input.
return debugTraces
return debugTraces && registry
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this definitely correct? Without checking out code it's hard to verify that you can destructure registry like this.

google-genai is using some experimental flag, see:

https://github.com/firebase/genkit/blob/main/js/plugins/google-genai/src/googleai/gemini.ts#L657-L661

Copy link
Member Author

@CorieW CorieW Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd go with what's in google-genai, as I've just realised the current runInNewSpan function where you pass in the registry is deprecated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

refactor: migrate googleai plugin to V2 Plugin API

2 participants