You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We stumbled across an issue the other day and confirmed the bug a couple of different ways. The bottom line is that when there is more than one override for a value (e.g. a default value, and then an optional override using an environment variable, and then an optional override using a DIFFERENT environment variable), if the environment variable is missing, we lose the default value and the config value will resolve to Python "None".
This is important for our use case since we use client-specific config overrides to allow us to be able to adapt to different environment variable in different environments (but sometimes we don't need the client override).
Examples
Simple example
This first example is the most basic I could break it down to: having two different optional environment variables in one config. This isn't our actual use case, but illustrates the problem succinctly:
With none of the optional environment variables set, you can see the 'password' evaluates to none. Expected result is that 'password' should be the default of "123.
This works properly/as expected if we have EITHER environment variable or BOTH environment variables set:
Our actual use case example
Our actual use case is that we have a default value set in reference.conf, with an optional override if our standard environment variable is set. We then have a client-specific config that we can use to override the reference.conf values, and have that set as optional as well. Our expected/desired outcome is that we'd use the client-specific environment variable if available; if not, we'd use the standard environment variable. Failing those, we should use the default value.
Below, you can see the setup. The parsed config is returning "None" for password in the situation where we don't have either of the optional environment variable set, but our expected value would be the default of "abc":
I have confirmed this issue occurs in versions 0.3.59 and 0.3.60.
The text was updated successfully, but these errors were encountered:
Description
We stumbled across an issue the other day and confirmed the bug a couple of different ways. The bottom line is that when there is more than one override for a value (e.g. a default value, and then an optional override using an environment variable, and then an optional override using a DIFFERENT environment variable), if the environment variable is missing, we lose the default value and the config value will resolve to Python "None".
This is important for our use case since we use client-specific config overrides to allow us to be able to adapt to different environment variable in different environments (but sometimes we don't need the client override).
Examples
Simple example
This first example is the most basic I could break it down to: having two different optional environment variables in one config. This isn't our actual use case, but illustrates the problem succinctly:
With none of the optional environment variables set, you can see the 'password' evaluates to none. Expected result is that 'password' should be the default of "123.
This works properly/as expected if we have EITHER environment variable or BOTH environment variables set:
Our actual use case example
Our actual use case is that we have a default value set in reference.conf, with an optional override if our standard environment variable is set. We then have a client-specific config that we can use to override the reference.conf values, and have that set as optional as well. Our expected/desired outcome is that we'd use the client-specific environment variable if available; if not, we'd use the standard environment variable. Failing those, we should use the default value.
Below, you can see the setup. The parsed config is returning "None" for password in the situation where we don't have either of the optional environment variable set, but our expected value would be the default of "abc":
I have confirmed this issue occurs in versions 0.3.59 and 0.3.60.
The text was updated successfully, but these errors were encountered: