ClientObservationConventionAdapter overwrites WebClient request attributes

[HaloFour]

Spring Boot version: 3.0.13

I have noticed that when using WebClient metrics with the built-in convention for adapting WebClientExchangeTagsProvider that the URI template is being stripped from the attributes of the ClientRequest. This is caused by the ClientObservationConventionAdapter trying to overwrite the attribute to ClientRequestObservationContext.getUriTemplate() before ClientRequestObservationContext.setUriTemplate(String) has been called.

Reproduction:

var clazz = Class.forName("org.springframework.boot.actuate.autoconfigure.observation.web.client.ClientObservationConventionAdapter");
var constructor = clazz.getDeclaredConstructors()[0];
constructor.setAccessible(true);
var adapter = (ClientRequestObservationConvention) constructor.newInstance("http.client.requests", new DefaultWebClientExchangeTagsProvider());

var registry = TestObservationRegistry.create();
var client = WebClient.builder()
        .observationRegistry(registry)
        .observationConvention(adapter)
        .build();

client.get()
        .uri("https://httpbin.org/{method}", "get")
        .retrieve()
        .bodyToMono(String.class)
        .block();


TestObservationRegistryAssert.assertThat(registry)
        .hasObservationWithNameEqualTo("http.client.requests")
        .that()
        .hasLowCardinalityKeyValue("uri", "/get"); // should be "/{method}"

I have worked around this by providing my own adapter convention which avoids overwriting the request attribute. Given this adapter convention has already been removed from Spring Boot 3.2 it might not be worth addressing, but I thought I would report it.

[bclozel]

Thanks for the report.

Spring Boot 3.1.x is almost out of OSS supported, scheduled in roughly a month (2024-05-18). While I do see similarities and inconsistencies (see spring-projects/spring-framework#29885), I believe this behavior has been this way for a long time now and I don't think we should change this right before cutting the OSS support. This is likely to break existing dashboards - arguably, they will break anyway when applications will move to the observation conventions in 3.2.x, since this adapter has been removed in that generation.

I'll discuss that with the team.

[bclozel]

I've had another look and it's definitely invalid behavior. I'm pushing a fix for 3.1.x as the existing implementation only breaks expectations. Thanks for your report!