[pkg//datadog] Default config fails round-trip validation

[iblancasa]

Component(s)

pkg/datadog

What happened?

The datadog exporter default config currently does not safely "survive" a full config round-trip through the Collector config system.

The issue is in pkg/datadog/config, where CreateDefaultConfig() initializes both deprecated settings and their canonical replacements in the same in-memory Go config struct.

That shape is usable as an in-memory Go struct, but once the config is marshaled and then decoded again, both the deprecated and canonical keys are present in the serialized config map. During decode, the existing config warning/validation logic correctly rejects configs that set both old and new settings at the same time.

Collector version

main

Environment information

No response

OpenTelemetry Collector configuration

Log output

Additional context

Found while working on open-telemetry/opentelemetry-collector#14599

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[github-actions]

Pinging code owners:

• pkg/datadog: @mx-psi @dineshg13 @liustanley @songy23 @mackjmr @jade-guiton-dd @IbraheemA

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[jade-guiton-dd]

Do we expect configs to survive such a round-trip in general anyway? configopaque.String redacting its contents seems like it would make that impossible.

[iblancasa]

Do we expect configs to survive such a round-trip in general anyway?

I think this should happen. We are implementing open-telemetry/opentelemetry-collector#11711 to ensure issues do not appear -I think this can help to avoid some possible issues when generating the config from the schemas-.

configopaque.String redacting its contents seems like it would make that impossible.

So far, didn't find any issues except some PRs I created in solving the problems -like this ticket-. So, I guess, we are fine.

[jade-guiton-dd]

So far, didn't find any issues except some PRs I created in solving the problems -like this ticket-. So, I guess, we are fine.

Have you tried using a Datadog exporter config with an API key set? That field uses the configopaque.String so it gets redacted by OpAMP and other config reporting methods, which means it shouldn't round trip.

I'll post a comment on that issue.