[confmap] Fix for unset env var setting non-string field.

[TylerHelmuth]

Description

Still working on making a new test for this scenario, but all existing tests pass.

Link to tracking issue

Fixes #10949

Testing

Manual testing showed the bug resolved, but I'd still like to get an e2e test to check it.

[TylerHelmuth]

This doesn't work, the reflected default value ends up being used instead of the config's default value. I think we'd need sampling_initial to be unset if the env var is not set in order to properly merge in the default value.

[codecov]

Codecov Report

Attention: Patch coverage is 71.42857% with 2 lines in your changes missing coverage. Please review.

Project coverage is 91.87%. Comparing base (17b39d1) to head (776fefa).
Report is 1 commits behind head on main.

Files	Patch %	Lines
confmap/confmap.go	71.42%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10950      +/-   ##
==========================================
- Coverage   91.88%   91.87%   -0.01%     
==========================================
  Files         411      411              
  Lines       19327    19330       +3     
==========================================
+ Hits        17759    17760       +1     
- Misses       1218     1219       +1     
- Partials      350      351       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[TylerHelmuth]

Maybe that is ok?

In the string situation the value would be getting set to "" which would also override any default string value. So

exporters:
  debug:
    verbosity: ${env:UNSET_VAR}

would be seen as

exporters:
  debug:
    verbosity: ""

Not

exporters:
  debug:
    verbosity: "basic"

We log a warning when an unset env var is detected.

[TylerHelmuth]

I've confirmed that prior to this regression the unset env var would result in the field being set with the type's default value, not the default value from CreateDefaultConfig. So this PR should be a return to that behavior.

[mx-psi]

LGTM, is there any way we can reproduce the panic in a unit test?

[mx-psi]

This test in confmap/internal/e2e/types_test.go panics in main but passes on this PR:

func TestIssue10949_UnsetVar(t *testing.T) {
	resolver := NewResolver(t, "types_expand.yaml")
	conf, err := resolver.Resolve(context.Background())
	require.NoError(t, err)

	var cfg TargetConfig[int]
	err = conf.Unmarshal(&cfg)
	require.NoError(t, err)
	require.Equal(t, 0, cfg.Field)
}

(edit: Also tested on 1c96225 (last commit before the panic happens) and confirmed that this the behavior we had before)

Could you add this/something like this as a test?

[TylerHelmuth]

@mx-psi added, thank you!