>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3620968. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !62 >>> <p>Eight classes inject <code>@logger.channel.kessai</code>, a service that exists only to be injected. Injecting it builds the channel every time one of those classes is built, which on almost every request is a channel nothing ever logs to. The factory builds one on demand instead, so a request that logs nothing pays for nothing.</p> <p>Core does both, so the count is not the argument: its own service files inject a prebuilt channel 27 times against 7 factory injections. What settles it is which classes get the benefit. <code>MediaEmbed</code> and <code>MailManager</code> call <code>$this-&gt;loggerFactory-&gt;get('media')</code> at the point of logging and build nothing otherwise; <code>ProviderRepository</code> and <code>OEmbedFormatter</code> assign the channel in their constructor and build it whether or not they log. <code>LoggerChannelTrait::getLogger()</code>, which is what every controller already uses, is the on-demand form.</p> <h3>What changes</h3> <p>A controller injects nothing new. <code>ControllerBase</code> already carries core's <code>LoggerChannelTrait</code>, so the factory and a lazy accessor are there for the asking, which is what the handoff controller has always done; the Worldline return controller drops its logger argument and does the same.</p> <p>The seven classes with no factory already available take <code>LoggerChannelFactoryInterface</code> as their last constructor argument and reach the channel through one small trait, so the channel is named once rather than at each of their call sites:</p> <pre>$this-&gt;getKessaiLogger()-&gt;warning('...', [...]);</pre><p>Neither name is arbitrary. <code>LoggerChannelTrait</code> declares a <code>protected $loggerFactory</code> and a <code>getLogger($channel)</code> taking a required argument, and both are fatal to reuse: promoting a readonly property of that name raises "Cannot redeclare non-readonly property as readonly", and a no-argument <code>getLogger()</code> raises "Declaration must be compatible". Both were confirmed rather than assumed. <code>getKessaiLogger()</code> and <code>$loggerChannelFactory</code> also stay clear of whatever core adds to a parent later.</p> <p>The <code>logger.channel.kessai</code> service definition goes with them. It existed to be injected, and after this nothing injects it.</p> <h3>Ordering</h3> <p>While each constructor is open, the logger moves to last. It sat between two collaborators in four classes and last in four others, which read as though it were part of the sequence rather than the cross-cutting concern it is. Drupal publishes no standard for this and <code>drupal/coder</code> ships no sniff for it, so this is house consistency rather than compliance. The argument order in the service files moves with it, since arguments are positional.</p> <h3>What it costs the tests</h3> <p>Two test classes captured what the engine logged by replacing the channel service, which stops intercepting anything: <code>LoggerChannelFactory::get()</code> builds its own channel and never looks up a container service by that name. They register a logger with the factory instead, which also back-fills channels already built. The buffer then receives every channel rather than just this module's, so the assertions filter on the channel the record carries. A third handed a logger straight to a constructor, and hands over the factory instead.</p> <p>AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code on the merge request. I reviewed and ran the work myself before posting it.)</p>