[google-adk-spring-ai] SpringAI beans are never auto-configured: @ConditionalOnBean(ChatModel) is evaluated before Spring AI model auto-configurations (missing ordering declaration)

[kongxubihai]

Environment

Component	Version
google-adk / google-adk-spring-ai	1.9.0
Spring AI (BOM)	2.0.1
Spring Boot	4.0.2
Java	25

Minimal reproduction

pom.xml (relevant parts):

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>4.0.2</version>
</parent>

<properties>
    <java.version>25</java.version>
    <spring-ai.version>2.0.1</spring-ai.version>
    <adk.version>1.9.0</adk.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>com.google.adk</groupId>
        <artifactId>google-adk</artifactId>
        <version>${adk.version}</version>
    </dependency>
    <dependency>
        <groupId>com.google.adk</groupId>
        <artifactId>google-adk-spring-ai</artifactId>
        <version>${adk.version}</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-starter-model-openai</artifactId>
    </dependency>
</dependencies>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.ai</groupId>
            <artifactId>spring-ai-bom</artifactId>
            <version>${spring-ai.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Application.java:

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }

    @Bean
    LlmAgent agent(SpringAI springAI) {
        return LlmAgent.builder()
                .name("demo-agent")
                .model(springAI)
                .instruction("You are a helpful assistant.")
                .build();
    }
}

application.yaml (dummy values are enough — the failure happens at bean-definition processing, before any remote call):

spring:
  ai:
    openai:
      base-url: https://api.openai.com
      api-key: dummy
      chat:
        model: gpt-4o-mini

Run: mvn spring-boot:run

Actual behavior

Application fails to start:

***************************
APPLICATION FAILED TO START
***************************

Description:

Parameter 0 of method agent in com.example.demo.DemoApplication required a bean
of type 'com.google.adk.models.springai.SpringAI' that could not be found.

Action:

Consider defining a bean of type 'com.google.adk.models.springai.SpringAI' in your configuration.

Running with --debug shows the root cause — the OpenAI ChatModel bean definition is registered, but SpringAIAutoConfiguration is processed before it, so all three SpringAI @Bean methods are skipped:

OpenAiChatAutoConfiguration matched:
   - @ConditionalOnProperty (spring.ai.model.chat=openai) matched
OpenAiChatAutoConfiguration#openAiChatModel matched:
   - @ConditionalOnMissingBean ... did not find any beans (OnBeanCondition)

SpringAIAutoConfiguration#springAIWithBothModels:
   Did not match:
      - @ConditionalOnBean (types: ...ChatModel, ...StreamingChatModel) did not find any beans
SpringAIAutoConfiguration#springAIWithChatModel:
   Did not match:
      - @ConditionalOnBean (types: ...ChatModel) did not find any beans of type ...ChatModel (OnBeanCondition)
SpringAIAutoConfiguration#springAIWithStreamingModel:
   Did not match:
      - @ConditionalOnBean (types: ...StreamingChatModel) did not find any beans

Note springAIEmbedding has the same problem (@ConditionalOnBean(EmbeddingModel.class)) — it fails silently (no bean, no error), which makes it even harder to notice.

Expected behavior

SpringAIAutoConfiguration registers a SpringAI bean whenever a ChatModel (and/or StreamingChatModel) is defined by Spring AI model auto-configurations, regardless of which provider starter is used.

Root cause

SpringAIAutoConfiguration guards its @Bean methods with @ConditionalOnBean(...), but declares no ordering relative to the auto-configurations that may provide those beans. Per the Spring Boot reference documentation, the result of @ConditionalOnBean depends on what has been processed so far, so an auto-configuration relying on it must be ordered after the configurations that register the matched beans.

google-adk-spring-ai 1.9.0 is built against Spring AI 2.x / Boot 4 (its POM depends on spring-ai-model:2.0.1 and spring-boot-autoconfigure:4.0.2), and since it compiles only against spring-ai-model (no provider modules), the Class-based after = ... attribute is not usable here — the string-based afterName attribute exists exactly for this case (non-existent class names are silently ignored by the sorter).

Suggested fix

Add an afterName list covering the Spring AI model auto-configurations, mirroring what Spring AI 1.x's own ChatClientAutoConfiguration did for the identical scenario (@ConditionalOnBean(ChatModel) with an unpredictable provider):

-@AutoConfiguration
+@AutoConfiguration(afterName = {
+    "org.springframework.ai.model.openai.autoconfigure.OpenAiChatAutoConfiguration",
+    "org.springframework.ai.model.openai.autoconfigure.OpenAiEmbeddingAutoConfiguration",
+    // remaining Spring AI 2.x model auto-configurations, e.g.:
+    // org.springframework.ai.model.anthropic.autoconfigure.AnthropicChatAutoConfiguration
+    // org.springframework.ai.model.ollama.autoconfigure.OllamaChatAutoConfiguration
+    // ... (package pattern: org.springframework.ai.model.<provider>.autoconfigure.*)
+})
 @ConditionalOnClass({SpringAI.class, ChatModel.class})
 @ConditionalOnProperty(prefix = "adk.spring-ai.auto-configuration", name = "enabled",
     havingValue = "true", matchIfMissing = true)
 @EnableConfigurationProperties({SpringAIProperties.class})
 public class SpringAIAutoConfiguration {

(Verified against Spring AI 2.0.1: org.springframework.ai.model.openai.autoconfigure.OpenAiChatAutoConfiguration / OpenAiEmbeddingAutoConfiguration. The other provider names above follow the 2.x package pattern and should be double-checked against the current source.)

An alternative design — the one Spring AI 2.0 itself adopted — is to drop the @ConditionalOnBean guards entirely and take ChatModel/StreamingChatModel as @Bean method parameters, which removes the ordering sensitivity altogether. The afterName fix is the smaller, backward-compatible change, though.

Workaround (for users on 1.9.0)

Define the SpringAI bean in application code — user-defined beans are processed before auto-configurations, and ADK's @ConditionalOnMissingBean(SpringAI.class) then backs off:

@Bean
SpringAI springAI(ChatModel chatModel) {
    return new SpringAI(chatModel, "gpt-4o-mini");
}

This works with any provider (it consumes the ChatModel abstraction), but every project using ADK + Spring AI has to copy it, so it is not a substitute for the upstream fix.

References

• Spring Boot reference — Creating your own auto-configuration / condition annotations: ordering matters for @ConditionalOnBean
• Spring AI 1.x ChatClientAutoConfiguration: same pattern solved with afterName over all provider auto-configurations
• Spring AI 2.0.1 ChatClientAutoConfiguration: same problem avoided via @Bean parameter injection instead of @ConditionalOnBean

[aron-intframe]

I reproduced this on 1.9.0. SpringAIAutoConfiguration on main hasn't changed since it was added (#482), so it still applies. The cause is the missing ordering declaration you point to. One more detail explains why it fails every time instead of now and then: when no ordering is declared, Boot's AutoConfigurationSorter.getInPriorityOrder (v4.0.2) sorts auto-configurations alphabetically first ("Initially sort alphabetically"). com.google.adk... always sorts ahead of org.springframework.ai..., so the ADK conditions are checked before any provider has registered its ChatModel.

What I ran: ADK 1.9.0, Spring AI 2.0.1, Boot 4.0.2, JDK 21, your pom/yaml, mvn package, then java -jar target/demo-0.0.1.jar.

1. Unmodified:

Parameter 0 of method agent in com.example.demo.DemoApplication required a bean of type 'com.google.adk.models.springai.SpringAI' that could not be found.
exit=1

2. Same app, with the SpringAI bean below declared in DemoApplication:

REPRO: SpringAI bean injected -> com.google.adk.models.springai.SpringAI
Started DemoApplication in 1.732 seconds
exit=0

3. Unmodified app, plus the main copy of SpringAIAutoConfiguration with just @AutoConfiguration(afterName = {"org.springframework.ai.model.openai.autoconfigure.OpenAiChatAutoConfiguration", "org.springframework.ai.model.openai.autoconfigure.OpenAiEmbeddingAutoConfiguration"}) added, compiled into the app so it replaces the jar's copy:

Auto-configuring SpringAI with both ChatModel and StreamingChatModel. Model: gpt-4o-mini
Auto-configuring SpringAIEmbedding with EmbeddingModel. Model: Unknown Embedding Model Name
Started DemoApplication in 1.335 seconds
exit=0

So your afterName fix works, and it also brings back the SpringAIEmbedding bean, which was being skipped with no error.

Workaround until a release: declare the bean yourself. User configuration is always processed before auto-configuration, and every ADK factory method is @ConditionalOnMissingBean(SpringAI.class), so they back off:

@Bean
SpringAI springAI(ChatModel chatModel, StreamingChatModel streamingChatModel) {
  return new SpringAI(chatModel, streamingChatModel, "gpt-4o-mini");
}

If you use embeddings, declare SpringAIEmbedding from your EmbeddingModel the same way.

Why the module's tests are green: SpringAIAutoConfigurationTest and SpringAIAutoConfigurationBasicTest both provide ChatModel through .withUserConfiguration(TestConfigurationWith...). User configuration always comes before auto-configuration, so those tests pass whether or not the ordering is declared. A regression test for this needs to supply the model through an auto-configuration class, so the sorter actually runs.

We keep running into tests like this, ones that can't fail whatever the real ordering is. Our notes on that pattern (ours): https://github.com/aron-intframe/agent-guards#the-one-rule

[hemasekhar-p]

Hi @kongxubihai, we really appreciate you reporting this issue and putting together a PR to fix it. I have successfully reproduced the issue you described. Both the issue and your PR are now under review by the team. We will keep you updated and let you know if we need any additional information. thank you.