Fresh installation floods dev log with kernel events

[therealahall]

Hello 👋🏼 my team and I are evaluating this as we utilize Symfony, but we've noticed that installing this package has dramatically increased the amount of kernel event notices we are getting in our logs. When we do not have this package installed, we see very few of these, if any, however, after installation, we'll see hundreds per second effectively making our logs useless. In one instance, it writes so much that one of my team members sees timeouts during web requests.

I know there's an option to add !event to our channels in monolog, or even split those out into a different log, but I haven't dug into what we could potentially lose there by not logging those out. I'm mostly looking to see if there's something I'm missing that could help clean these up or if there's another path to take here.

Some potentially helpful information:
Symfony 5.4
Largely mac environment, m1+, but some Linux
Xdebug enabled
PHP 8.2
Installed via composer require into the project

Example log

{
    "message": "Notified event \"kernel.finish_request\" to listener \"Symfony\\Component\\HttpKernel\\EventListener\\RouterListener::onKernelFinishRequest\".",
    "context": {
        "event": "kernel.finish_request",
        "listener": "Symfony\\Component\\HttpKernel\\EventListener\\RouterListener::onKernelFinishRequest",
        "requestId": "29538686-95d2-11ee-95c6-cf04550d2ce3",
        "environment": "dev",
        "release": "unknown"
    },
    "level": 100,
    "level_name": "DEBUG",
    "channel": "event",
    "datetime": "2023-12-08T14:00:36.492890+00:00",
    "extra": {}
}

[Wirone]

Fixer does not have anything to do with Symfony's HTTP events, actually it does not hook into any kernel events within app where it's installed. It's a CLI tool separated from the app itself and should not be installed outside of the dev stage.

One scenario I can think of is that during the installation of Fixer some other packages were installed/updated and some components were auto-discovered by Symfony and registered in a DI container. Please verify what packages were modified and provide that info here, if you can.

Also please check how it works if you install php-cs-fixer/shim instead of a regular package that requires some other dependencies 🙂.

[therealahall]

Yeah it makes zero sense why after installation we see a large increase of these messages. I was able to confirm that the installation of that package (and its dependencies) was the source of this by removing it and rebuilding our application. It was definitely in the dev space.

I've worked around it by updating our dev container to just pull in the phar so that it's available without enabling all of the dependencies in the project. I'll give the shim a try and see if I can recreate it, but here's the changed packages from doing the composer install. All of these appear to be dependencies of friendsofphp/php-cs-fixer directly

In composer.json under dev

• "friendsofphp/php-cs-fixer": "^3.40",

In composer.lock under dev

• "name": "composer/pcre", "version": "3.1.1",
• "name": "composer/semver", "version": "3.4.0",
• "name": "composer/xdebug-handler", "version": "3.0.3",
• "name": "friendsofphp/php-cs-fixer", "version": "v3.40.2",
• "name": "sebastian/diff", "version": "5.0.3",
• "name": "symfony/stopwatch", "version": "v5.4.21",

In symfony.lock, the only change was the addition of the package

[Wirone]

IMHO it's symfony/stopwatch that is causing changes in your logs. I can't say for sure, but I believe existence of this package enables some listeners in the framework and it starts to log request events that was not the case before. I believe installing shim version of Fixer should solve your problem because it will no longer install additional packages along with Fixer 🙂.

[therealahall]

Yeah, looking at that package, that does look like it would have ended with the same result that I have with it building directly in our dev container. I'm going to mark your last response as the answer as what we have is working well for us now and if I need to revisit it in the future, I'll check the shim package.

Thanks!