Connection auto-configurations are not guarded by the model enablement properties and can fail application startup

Three connection auto-configurations define an eagerly instantiated singleton
that validates its configuration inside the @Bean method, but unlike the model
auto-configurations they feed, they carry no spring.ai.model.* condition. They
are applied whenever the artifact is on the classpath, and no property can switch
them off: setting the model to none disables the model auto-configuration while
the connection one still runs, throws, and fails the application context.

Verified on main (b5eb027).

Affected

Auto-configuration	Property condition	Failure when nothing is configured
GoogleGenAiEmbeddingConnectionAutoConfiguration	none	IllegalArgumentException: Google GenAI project-id must be set!
GoogleGenAiImageConnectionAutoConfiguration	none	IllegalStateException: Incomplete Google GenAI configuration: Provide 'api-key' for Gemini API or 'project-id' and 'location' for Vertex AI.
VertexAiEmbeddingConnectionAutoConfiguration	none	IllegalArgumentException: Vertex AI project-id must be set!

The sibling auto-configurations in the same modules are all guarded:

Auto-configuration	Property condition
GoogleGenAiChatAutoConfiguration	spring.ai.model.chat
GoogleGenAiTextEmbeddingAutoConfiguration	spring.ai.model.embedding.text
GoogleGenAiImageAutoConfiguration	spring.ai.model.image
VertexAiTextEmbeddingAutoConfiguration	spring.ai.model.embedding.text
VertexAiMultiModalEmbeddingAutoConfiguration	spring.ai.model.embedding.multimodal

Reproduce

1. Add spring-ai-starter-model-google-genai-embedding.
2. Set spring.ai.model.embedding.text=none.
3. Start the application.

The context fails with Google GenAI project-id must be set!. The same applies to
the other two rows with their respective properties.

Why this is not only a dependency problem

#6171 removed the embedding artifact from the chat starter, which covers the case
where the artifact arrives transitively and is unwanted. It does not cover an
application that depends on the starter on purpose, because it uses the provider
in some environments and selects another one elsewhere. There the artifact is
wanted on the classpath and the missing condition is the only thing left.

#6130 identified this before it was closed as a duplicate:

There is @ConditionalOnProperty annotation on
GoogleGenAiTextEmbeddingAutoConfiguration, so it should disable it, but not on
GoogleGenAiEmbeddingConnectionAutoConfiguration, which is not ideal because it
can't be disable like this for now.

The fix is not uniform across the three

For the two Google GenAI classes the connection bean feeds exactly one model
auto-configuration, so reusing that model's property works directly. #6794 does
this for the embedding one.

VertexAiEmbeddingConnectionDetails is different: it is consumed by both
VertexAiTextEmbeddingAutoConfiguration and
VertexAiMultiModalEmbeddingAutoConfiguration. A single @ConditionalOnProperty
on spring.ai.model.embedding.text would break an application that disables text
embedding but still uses multimodal embedding. That one needs a condition over
both properties, or a different mechanism.

Related

This looks like the general problem raised in #6130:

Looks like to me there is a general issue on more focused activation of
autoconfiguration we should discuss

• #5077 proposes the same guard for OllamaApiAutoConfiguration, which has the
  same shape (@ConditionalOnClass and @EnableConfigurationProperties only).
  Open since December 2025.
• #5989 is an OpenAI variant of a connection auto-configuration failing startup.
• #6156 gated on the presence of credentials rather than the enablement property
  and was not merged.

Question

Would you prefer per-class conditions reusing the existing spring.ai.model.*
properties, with matchIfMissing = true to preserve the current default-on
behaviour, or a shared mechanism for connection auto-configurations that covers
every provider at once?

I am happy to prepare either. #6794 is the narrow per-class version for one of
the three, and I can extend it to the image connection and the Vertex AI one once
the direction is clear.

Start with GoogleGenAiEmbeddingConnectionAutoConfiguration, GoogleGenAiImageConnectionAutoConfiguration, and VertexAiEmbeddingConnectionAutoConfiguration, then compare their sibling model auto-configurations and the approach in #6794. Reproduce the three failures with the listed spring.ai.model.* properties; done means disabled models no longer create failing connection beans while text and multimodal Vertex AI remain independently usable.