Looking at your comments here, I wonder if we should keep#54668 or not?
Maybe@yann-eugone can tell use how he wires the client so that we understant why adding LoggerAwareInterface helps?
I'm not keen on the bump in composer.json, it'd prefer not doing it.

Sure,

On that project, constructing anHttpClientInterface is a thing that is done at runtime, because it all depend on configuration (what service you are trying to call)

finalclass HttpClientFactory{publicfunction__construct(privatereadonlyHttpClientInterface$http,    ) {    }publicfunctioncreate(Config$config,LoggerInterface$logger):HttpClientInterface    {$client =match (...) {            Config::A =>$this->clientA(),            Config::B =>$this->clientB(),        };if ($clientinstanceof LoggerAwareInterface) {$client->setLogger($logger);        }return$client;    }privatefunctionclientA():HttpClientInterface    {return$this->http->withOptions([            ...        ]);    }privatefunctionclientB():HttpClientInterface    {return$this->http->withOptions([            ...        ]);    }}

I'm usingSymfony\Contracts\HttpClient\HttpClientInterface::withOptions because it's way safer for unit testing to clone a client provided from a constructor than having to build from the ground.

As you can see, the$logger is provided in the factory method, because each feature has it's own logger instance, but they all share dependency onHttpClientFactory

#[WithMonologChannel('feature1')]finalclass Feature1{publicfunction__construct(privatereadonlyHttpClientFactory$httpClientFactory,privatereadonlyLoggerInterface$logger,    ) {    }publicfunctionmethod(Config$config):void    {$http =$this->httpClientFactory->create($config,$this->logger);...    }}#[WithMonologChannel('feature2')]finalclass Feature2{publicfunction__construct(privatereadonlyHttpClientFactory$httpClientFactory,privatereadonlyLoggerInterface$logger,    ) {    }publicfunctionmethod(Config$config):void    {$http =$this->httpClientFactory->create($config,$this->logger);...    }}

I've only proposed addingLoggerAwareInterface because I saw that actual clients already implemented it, so I believed it was just about someone forgetting to add it everywhere.

What about supporting passing the logger towithOptions() instead? This could look something like this in your factory then:

privatefunctionclientA(LoggerInterface$logger):HttpClientInterface{return$this->http->withOptions(['extra' => ['logger' =>$logger,        ],// ...    ]);}

I wonder if we need this PR at all: to me, the actual http client that does log should already have the logger wired. Did you check this aspect?

to me, the actual http client that does log should already have the logger wired

I agree with this reasoning. That's why I suggest to revert implementing theLoggerAwareInterface in HTTP client decorators.

I don't have any opinion on this honestly
But why removingsetLogger on decorated clients, but not on actual ones ?

The actual clients do use the logger themselves. They do not use this property to configure another client. We can argue if using the interface was the right decision back when we introduced it, but that’s a different topic.

Thank you@xabbuh.

We could even deprecate existing setLogger proxies.

see#54806