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.

Comment From: 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.

Comment From: 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!

Comment From: ranideepa

@bclozel we have upgraded from spring 2.6.6 version to 3.0.7 , in our project and facing the same issue for http webClient requests, the URI_TEMPLATE_ATTRIBUTE is not getting set and its causing lot of uri tags to be generated what is the way to fix this issue fix 3.07 version?

Comment From: bclozel

@ranideepa I don't think your problem is related as with this issue the URI_TEMPLATE_ATTRIBUTE was set. Spring Boot 3.0.x is now out of OSS support. Please consider upgrading to a supported version.

Comment From: ranideepa

@bclozel sure ,we will be considering the option to upgrade to newer version, but until we do this can you suggest some workaround to fix this issue of uri tag not correctly getting set which is causing lot of uri tags to be generated. as it was working fine in 2.6.6 version and issue started after upgrading to 3.0.7

Comment From: bclozel

Sure. I would suggest asking a question on StackOverflow.

Comment From: ranideepa

@bclozel yes have tried few workarounds form stackOverflow to explicitly set the URI_TEMPLATE_ATTRIBUTE , in attributes while building webClient but it doesn't seem to be working

Comment From: bclozel

Then it's probably a different problem. Try asking a new question, showing how you are using the client and what symptom you are seeing.