Guard GoogleGenAiEmbeddingConnectionAutoConfiguration with the model enablement property - #6794
Open
hoyo1744 wants to merge 1 commit into
Open
Conversation
Apply the model enablement property condition already used by GoogleGenAiTextEmbeddingAutoConfiguration, so the connection is not created when Google GenAI embeddings are disabled. Without it the auto-configuration runs unconditionally and falls back to Vertex AI mode, failing startup with "Google GenAI project-id must be set!" for applications that do not use Google GenAI embeddings. Signed-off-by: hoyong.eom <hoyo1744@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GoogleGenAiEmbeddingConnectionAutoConfigurationis not guarded by themodel enablement property, so it is applied whenever the artifact is on
the classpath. When nothing is configured it falls back to Vertex AI mode
and fails the context:
This means adding
spring-ai-starter-model-google-genai-embeddingbreaksstartup for applications that do not use Google GenAI embeddings, and
spring.ai.model.embedding.text=nonedoes not help because the conditionis never evaluated.
Reproduce
spring-ai-starter-model-google-genai-embedding.spring.ai.model.embedding.text=none(or leave everything unset).Relation to previous reports
The same symptom was reported in #6130 and closed as a duplicate of
#6171, which removed the embedding artifact from the chat starter. That
resolves the reported case, where the artifact was pulled in
unintentionally.
It does not cover this one. Here the embedding starter is added on
purpose, because the application does use Google GenAI embeddings in some
environments and selects another provider in others. Since the artifact
is wanted on the classpath, dependency removal is not an option and the
missing condition is the only thing left.
This is exactly what was pointed out in #6130:
Unlike #6156, which gated the auto-configuration on the presence of
credentials, this reuses the existing model enablement property so that
the connection and the model it feeds share one switch.
See #6130
See #6171
Inconsistency
The sibling auto-configurations in the same module are guarded, the
connection one is not:
GoogleGenAiChatAutoConfigurationspring.ai.model.chatGoogleGenAiTextEmbeddingAutoConfigurationspring.ai.model.embedding.textGoogleGenAiImageAutoConfigurationspring.ai.model.imageGoogleGenAiEmbeddingConnectionAutoConfigurationChange
Applies the same condition already used by
GoogleGenAiTextEmbeddingAutoConfiguration, so the connection and themodel it feeds share a single switch.
matchIfMissing = truekeeps thecurrent default-on behaviour, so applications that configure nothing are
unaffected.
Adds
GoogleGenAiEmbeddingConnectionAutoConfigurationTestscoveringexplicit enable, default enable,
none, another provider, and that thecontext starts when nothing is configured.
Note
GoogleGenAiImageConnectionAutoConfigurationhas the same missingcondition. I left it out because its bean method does not fail fast the
same way and I could not confirm a broken startup for it. Happy to
extend this PR if you would like both aligned.
This may also be a small piece of the broader auto-configuration
activation discussion raised in #6130 and #5989.