SpringBoot Error creating bean with name 'prometheusMeterRegistry': Requested bean is currently in creation when defining a HikariDataSource and configuring its MeterRegistry

After moving from spring-boot 2.6.7 to 2.7.0 appeared cycle dependency error, related to PrometheusMeterRegistry and DataSourcePoolMetricsAutoConfiguration:

Error creating bean with name 'prometheusMeterRegistry': Requested bean is currently in creation: Is there an unresolvable circular reference'

It happens if bean, like below, is present in app configuration:

@Bean
public DataSource dataSource(MeterRegistry meterRegistry)  {
        HikariConfig poolConfiguration = new HikariConfig();
        poolConfiguration.setJdbcUrl("jdbc:mariadb://localhost:3306/test_db");
        poolConfiguration.setMetricRegistry(meterRegistry);
        return new HikariDataSource(poolConfiguration);
 }

After some investigations, I saw that MeterRegistryPostProcessor.postProcessAfterInitialization() calls public void bindTo(MeterRegistry registry) for all MeterBinders, and when DataSourcePoolMetadataMeterBinder.bindTo() or HikariDataSourceMeterBinder.bindTo() is called, exception appears.

dependencies: spring-boot 2.7.0, micrometer-core and micrometer-registry-prometheus : 1.9.1, HikariCP 5.0.1;

Looks like cyclic dependency was there always, but after the last updates to DataSourcePoolMetricsAutoConfiguration it causes exception.

Comment From: wilkinsona

Thanks for the report. The change in behavior is due to the fix for https://github.com/spring-projects/spring-boot/issues/30282 which we were aware was a little risky.

Are you aware that DataSourcePoolMetricsAutoConfiguration will automatically bind Hikari metrics for every DataSource bean that is a HikariDataSource? You may be able to avoid the problem by changing your dataSource method to the following:

@Bean
public DataSource dataSource()  {
        HikariConfig poolConfiguration = new HikariConfig();
        poolConfiguration.setJdbcUrl("jdbc:mariadb://localhost:3306/test_db");
        return new HikariDataSource(poolConfiguration);
}

Longer term, we could fix this by reverting the changes for #30282 at the cost of reintroducing the problem with lazy initialization. If we chose not to do that, I believe this is the same problem as https://github.com/spring-projects/spring-boot/issues/30636 is tracking.

Comment From: ailjushkin

@wilkinsona Hi, I'm also faced with the problem while dealing with rabbitmq metrics, could you please explain how to work around this problem?

Running with Spring Boot v2.7.1, Spring v5.3.21

[C:\work\vcs\xxx\xxx-backend-webapp\target\classes\com\xxx\xxx\billing\openapi\notifications\rabbit\RabbitConnectionFactoryConfiguration.class]: Unsatisfied dependency expressed through constructor parameter 7; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'prometheusMeterRegistry': Requested bean is currently in creation: Is there an unresolvable circular reference?

Description:

The dependencies of some of the beans in the application context form a cycle:

   webMvcMetricsFilter defined in class path resource [org/springframework/boot/actuate/autoconfigure/metrics/web/servlet/WebMvcMetricsAutoConfiguration.class]
┌─────┐
|  prometheusMeterRegistry defined in class path resource [org/springframework/boot/actuate/autoconfigure/metrics/export/prometheus/PrometheusMetricsExportAutoConfiguration.class]
↑     ↓
|  commonMetricsConfiguration defined in file [C:\work\vcs\xxx\xxx-backend-webapp\target\classes\com\xxx\xxx\billing\openapi\app\configs\metrics\CommonMetricsConfiguration.class]
↑     ↓
|  componentStatusService defined in class path resource [com/peterservice/bssbox/common/autoconfigure/HealthCheckAutoConfiguration.class]
↑     ↓
|  rabbitHealthCheck defined in class path resource [com/peterservice/bssbox/common/autoconfigure/RabbitHealthCheckAutoConfiguration.class]
↑     ↓
|  rabbitTemplate defined in class path resource [org/springframework/boot/autoconfigure/amqp/RabbitAutoConfiguration$RabbitTemplateConfiguration.class]
↑     ↓
|  rabbitConnectionFactoryConfiguration defined in file [C:\work\vcs\xxx\xxx-backend-webapp\target\classes\com\xxx\xxx\billing\openapi\notifications\rabbit\RabbitConnectionFactoryConfiguration.class]
└─────┘

MeterRegistry bean is autowired into my configuration to bind meter registry into rabbitmq connectionfactory

private void bindMetrics(CachingConnectionFactory connectionFactory) {
        connectionFactory.getRabbitConnectionFactory().setMetricsCollector(
                new MicrometerMetricsCollector(
                        meterRegistry,
                        METRIC_NAME_PREFIX + "rabbitmq",
                        Tags.of(TAG_VIRTUAL_HOST, connectionFactory.getVirtualHost(),
                                TAG_CONNECTION_STRING, rabbitProperties.determineHost() + ":" + rabbitProperties.determinePort()))
        );
    }

Comment From: wilkinsona

@ailjushkin #30636 is a better fit for your problem. Please comment there.

Comment From: ConradGroth

I ran into the following issue after an upgrade of spring-boot from 2.4.2 to 2.7.5, which is maybe caused by the described problem: The two metrics jdbc.connections.active and jdbc-connections.idle were not present anymore, although they are still mentioned in the class o.s.b.actuate.metrics.jdbc.DataSourcePoolMetrics. Meanwhile the metrics hikaricp.connections.active and hikaricp.connections.idle were present. I started my app in debug mode and set a breakpoint in bindTo(MeterRegistry registry). I saw that for creating the jdbc metrics the dataSource was still under construction, while during creation of the hikaricp metrics the dataSource was fully initialized.

If somebody thinks my issue is different from the original issue description I can also open a new issue, but for me it sounds like the same root cause.

We use HikariCP 4.0.3 and micrometer-registry-prometheus 1.9.5

Comment From: wilkinsona

Closing in favor of #30636 that has been fixed in 3.0.x and later. It's too risky to attempt anything in 2.7.x as it nears the end of its OSS support period.