Skip to content

Env variable processor return empty string when used with default. #57442

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
Wiktor6 opened this issue Jun 18, 2024 · 1 comment
Open

Env variable processor return empty string when used with default. #57442

Wiktor6 opened this issue Jun 18, 2024 · 1 comment
Labels
Bug DependencyInjection Status: Needs Review

Comments

@Wiktor6
Copy link

Wiktor6 commented Jun 18, 2024 •
edited
Loading

Symfony version(s) affected

6.4.8

Description

I'm updating my app from symfony v6.1.12 to v6.4.8 and behavior of env processor changed.

Before update env %env(string:default::ENV_NAME)% return null, but now it return empty string.

I found some PRs and issues, but there was fix to fix to fix, and I'm little bit confused what is the right way.

  1. [DependencyInjection] Fix casting scalar env vars from null #50517

  2. [DependencyInjection] Fix autocasting null env values to empty string #50837

  3. [DependencyInjection] Fix autocasting null env values to empty string with container.env_var_processors_locator #51198

  4. Environment variable typecast processors return null when used in conjunction with default: #50415

  5. Null environment variable cast to empty string #50815

In documentation there is "When the fallback parameter is omitted (e.g. env(default::API_KEY)), then the returned value is null.". I think 3rd PR says that null value shouldn't be casted to empty string.

Also, I modified my env to default::ENV_NAME and i have the same problem as described here

Invalid type for path "infrastructure_tools.healthChecks.baseAuthUser". Exp  
  ected one of "bool", "int", "float", "string", but got one of "bool", "int"  
  , "float", "string", "array".

How to reproduce

Pass the following as an argument to a Symfony service. Do not set the value of ENV.

final class EnvironmentService
{
    public function __construct(
        private ?string $env,
    ) {}
}
# services.yaml
\EnvironmentService:
  arguments:
    $env: '%env(string:default::ENV)%'

Symfony container build will fail due to null being passed as the $boolFlag which has to be a bool.

Possible Solution

No response

Additional Context

No response
@Wiktor6 Wiktor6 added the Bug label Jun 18, 2024
@narcoticfresh
Copy link

narcoticfresh commented Nov 26, 2024 •
edited
Loading

@Wiktor6
i currently have similar issues in trying to migrate our projects to dotenv in the first place. and it's a rather confusing situation - you found the same PRs as I did.

--> first of, I'm a bit confused why you have code examples about a string env and show errors based on that - but then in the last sentence you talk about a bool param? how come - so maybe my issue is not related. bool params are easy to solve as they can always and easily be defined into a boolean default.

i want to step back..

as i understand it, consensus is:

  • string: env processor casts to string and returns '' (empty string) even if null value - this was different before and was changed within a minor release which by itself is a semver violation
  • in order to get the "old" behavior that many of us rely on (including me) - we want to have null - we must prefix it with default:: to then use the default env processor which does return null.

it is indeed confusing and this kind of very important distinction is only marginally - but it is - documented.

you mentioned this message:

Invalid type for path "infrastructure_tools.healthChecks.baseAuthUser". Exp  
  ected one of "bool", "int", "float", "string", but got one of "bool", "int"  
  , "float", "string", "array".

i am at that point of my conversion journey - and i didn't know if it should be a separate issue or not.

and now an important distinction: this error seems to stem from a symfony configuration that defines a scalar config value (infrastructure_tools.healthChecks.baseAuthUser) - but it does now seem to check the return type of the referencend env processor default - which is bool|int|float|string|array and thus fails because of the array!

@nicolas-grekas
i don't know if mentions reach you - but it is sadly a logical mistake just to define bool|int|float|string|array as types of the default env processor - logically, the default processor inherits whatever "child processor(s)" it has defined - even if it defaults back to string (which is the default). it should be a dynamic property of the processor. do you share that sentiment?

so the very nice idea of even introduce typed env processors and even hooking that up to Configuration component processing leads to many many issues ;-) expensive feature..

all this env processing stuff seems a bit messy and i'm sure some years down the line it will be rolled up more cohesive - but that's what we have now ;-)

luckily we can define our own processors to workaround as needed..

@Wiktor6
if you follow up with a more detailed description of your issue please (is it string or boolean based?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug DependencyInjection Status: Needs Review
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@narcoticfresh @xabbuh @carsonbot @Wiktor6