ddtrace/tracer: fixed precedence ordering of configuration options

[dianashevchenko]

Previously, environment variables could override in-code settings. PR fixes the precedence order of configuration options to be:

1. Explicit option set by the user (in-code)
2. Env var
3. Default value

Fixes #1231

[gbbr]

Thanks for doing this.

We also need a regression test. There should be a test which reproduces the issue reported and fails without this PR, and passes with this PR.

[gbbr]

Probably best to get rid of this completely and follow the same pattern as the other settings. We can move the env. var. checks together with the rest of the env. var checks for the other options.

[dianashevchenko]

We would have to do it after running all the in-code options, I doubt that this change would contribute to cleaner code. Also, since it's in a separate function order of precedence is clear, no need to worry about someone moving around pieces of code

dd-trace-go/ddtrace/tracer/option.go

Lines 212 to 233 in 77eff54

	forEachStringTag(v, func(key, val string) { WithServiceMapping(key, val)(c) })
	}
	if v := os.Getenv("DD_TAGS"); v != "" {
	forEachStringTag(v, func(key, val string) { WithGlobalTag(key, val)(c) })
	}
	if _, ok := os.LookupEnv("AWS_LAMBDA_FUNCTION_NAME"); ok {
	// AWS_LAMBDA_FUNCTION_NAME being set indicates that we're running in an AWS Lambda environment.
	// See: https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html
	c.logToStdout = true
	}
	c.logStartup = internal.BoolEnv("DD_TRACE_STARTUP_LOGS", true)
	c.runtimeMetrics = internal.BoolEnv("DD_RUNTIME_METRICS_ENABLED", false)
	c.debug = internal.BoolEnv("DD_TRACE_DEBUG", false)
	c.enabled = internal.BoolEnv("DD_TRACE_ENABLED", true)
	c.profilerEndpoints = internal.BoolEnv(traceprof.EndpointEnvVar, true)
	c.profilerHotspots = internal.BoolEnv(traceprof.CodeHotspotsEnvVar, true)
	for _, fn := range opts {
	fn(c)
	}
	WithGlobalTag(ext.RuntimeID, globalconfig.RuntimeID())(c)
	if c.env == "" {

As for the regression test, we have up to date TestResolveAgentAddr, which verify correct order of in-code options, env variables, and default values.

dd-trace-go/ddtrace/tracer/transport_test.go

Lines 80 to 88 in 77eff54

	func TestResolveAgentAddr(t *testing.T) {
	for _, tt := range []struct {
	in, envHost, envPort, out string
	}{
	{"host", "", "", fmt.Sprintf("host:%s", defaultPort)},
	{"www.my-address.com", "", "", fmt.Sprintf("www.my-address.com:%s", defaultPort)},
	{"localhost", "", "", fmt.Sprintf("localhost:%s", defaultPort)},
	{":1111", "", "", fmt.Sprintf("%s:1111", defaultHostname)},
	{"", "", "", defaultAddress},

[gbbr]

As for the regression test, we have up to date TestResolveAgentAddr, which verify correct order of in-code options, env variables, and default values.

Great! I didn't notice it at first, the Github diff was not too great.

[...] I doubt that this change would contribute to cleaner code [...]

It's about being consistent. Also, you are passing an empty string to a function which is not used anywhere else and technically its argument has no value. You are intentionally passing bad input to force a certain code path. I don't think that's the right approach. It's an old piece of code. Better to get rid of it and be consistent. Or am I missing something? Why do we need it?

[dianashevchenko]

I reckon it's better to have the logic in the separate function, because otherwise 'configuration precedence order' relies only on the position in the code, which could be changed accidentaly in the future. Instead, I'll remove the arguments to the resolveAddr func and update tests according to that