Julien Viet

@geoand here is the implementation for Vert.x 5.1 with the Vert.x HTTP metrics SPI modifications, do you mind having a look to ensure we are on the expected track ?...

@geoand that will not work for multiple concurrent requests I think because they might share the same context unless you have a way to create a key from the request...

I am thinking of two possible options: 1. we provide access to the underlying http client request object created by the client metrics (like `HttpServerRequestInternal#metric()`) 2. or a method to...

> > we provide access to the underlying http client request object created by the client metrics (like HttpServerRequestInternal#metric()) > > I don't think this would help in my case,...

@geoand how about we introduce a new method to create the request metric and make it available in the request before it is sent and provide access to this metric...

> If we do that, when would `requestInit` be called? that would be created when the `HttpClientRequestImpl` is instantiated (so almost immediately).

@geoand that allow to retrieve the metrics object created by the metrics implementation and modify its state, e.g. we could imagine something like ```java ClientRequestMetric metric = (ClientRequestMetric)request.metric(); metric.label =...

> @vietj I used [eclipse-vertx/vert.x#5835](https://github.com/eclipse-vertx/vert.x/pull/5835) to verify that this approach would work for Quarkus so that confirms it allows you to implement the use case and we could merge it...

can you provide a reproducer that does not use docker compose ?

how does that work ? I ran mvn test and everything worked