monolog-bundle: strange configuration parsing of monolog, ??? BC-break after release of 3.4.0 ???

Looks like the same type of error after 3.4 upgrade :

Invalid configuration for path "monolog.handlers.slack": You can only use excluded_http_codes/excluded_404s with a FingersCrossedHandler definition                                                                                                                                                       
In ExprBuilder.php line 189:
You can only use excluded_http_codes/excluded_404s with a FingersCrossedHandler definition

I managed to reproduce it. Everything is well explained in this comment

And the following fix makes your application working (and more robust)

I’ve been missing something. An mergable configuration can be unset using excluded_404s: false

thanks @PetrHeinz

---

I don’t think we can do anything here. using ->performNoDeepMerging() will break too many applications.

So you should unset the configuration that are not compatible with your handler:

monolog:
    handlers:
        main:
            # change "fingers_crossed" handler to "group" that works as a passthrough to "nested"
            type: group
            members: [ nested ]
            excluded_404s: false

@TamasSzigeti

You application can not boot:

In Configuration.php line 402:
                                                                         
  Warning: array_map(): Expected parameter 2 to be an array, bool given  

---

Anyway, let take a step back on this issue.

What do you (all) have in mind when you configure monolog globally (config/packages/monolog.yaml) then per env (config/packages/dev/monolog.yaml) ? What do you think symfony should do // What did you expect ?

For now, symfony process configuration like following:

It loads the global configuration first:

monolog:
    handlers:
        main:
            type: fingers_crossed
            action_level: error
            handler: nested
            excluded_http_codes: [404, 405]

Then it (try to) merges it with the env configuration:

monolog:
    handlers:
        main:
            type: stream
            path: "%kernel.logs_dir%/%kernel.environment%.log"
            level: debug
            channels: ["!event"]
            excluded_http_codes: false

So this results in something really strange. Which configuration should win? The last one? Why? This could be determined by the kernel though:

    protected function configureContainer(ContainerBuilder $container, LoaderInterface $loader): void
    {
        // ...
        // global
        $loader->load($confDir.'/{packages}/*'.self::CONFIG_EXTS, 'glob');
         // per env
        $loader->load($confDir.'/{packages}/'.$this->environment.'/**/*'.self::CONFIG_EXTS, 'glob');

But anyway, what should be done? Should we drop all the previous configuration if a new configuration is met with the same name?

@COil Your usage of MonologBundle was incorrect, and someone added a check to ensure the configuration was correct. We have documented Our Backward Compatibility Promise. I may be wrong, but PR #271 did not violate this promise, isn’t?

This is not covered by the BC promise