Instead of throwing an EnvParameterException maybe this could log the concern somehow at a very low level? I'm not sure if a logger is available at this point though.

Another option would be to not trigger the error if that field gets overridden by an extending yaml (import resource).

👎 see the thread you linked: this was done on purpose. Env vars are no supposed to be allowed in every config options/parameters. So this error tells you when you did such mistake.

Here is a use case of environment variables in config that is not a mistake, but produces an error.

symfony_prod.yml

monolog:
    handlers:
        main:
            type: loggly
            token: "%env(LOGGLY_TOKEN)%"

symfony_prod_ecs.yml

imports:
    - { resource: symfony_prod.yml }

monolog:
    handlers:
        main:
            type: stream

Error:

[Symfony\Component\DependencyInjection\Exception\EnvParameterException]
Incompatible use of dynamic environment variables "LOGGLY_TOKEN" found in parameters.

If you change your config to this, does it fix the issue? Removing a generic check to prevent a specific false positive (I agree it can be seen as such) is too broad (I didn't think about a more specific fix). I'm still -1 with the current patch.

symfony_prod_ecs.yml

imports:
    - { resource: symfony_prod.yml }

monolog:
    handlers:
        main:
            type: stream
            token: ~

Sorry, I should have pointed out that even token: ~ didn't fix the issue for me. I'll re-verify this on Monday, too.

Confirmed. Even if you use ~ (or any value) to override an %env()% value you will get an exception.

This means that we cannot use environment variables in a config.yaml if you ever need to override, swap or un-use that environment variable in any extending config(s).

OK, thanks. This PR is too broad, we should seek for a more specific fix.

Closing as explained. Issue #23520 should be used to track the progress on this topic instead.