Problem
When ADP config keys are propagated to the Core Agent (e.g. via PRs like datadog-agent#51390), the default values defined in ADP config.rs and in the Core Agent common_settings.go can drift silently.
In practice, ADP's defaults are dead code — the Core Agent always propagates its own defaults to ADP at runtime. But this creates a risk: developers may set a default in ADP and assume it's the customer-facing value, neglecting to propagate changes (or new defaults) to the Core Agent.
Related: #1649
Options considered
Option 1 — Remove defaults from ADP; rely entirely on Core Agent defaults
Simple to implement, but not fully viable: Rust's type system and serde require default values to be provided even when they'll never be used in practice.
Option 2 — ADP generates an artifact that Core Agent consumes to determine defaults
Keeps config definition close to the source of truth. Theoretically best, but requires new infrastructure to "dump" ADP defaults in a form the Core Agent can ingest. No such machinery exists today.
Option 3 — Tests that compare ADP and Core Agent default configs
Conceptually simpler than option 2. Could work by default-constructing Saluki structs and comparing them against schema defaults. Also requires infrastructure that doesn't yet exist.
Current thinking
Options 2 and 3 are both viable long-term solutions but require upfront investment to build comparison/export machinery. A process bandaid (e.g. a checklist or PR template reminder to propagate default changes to the Core Agent) may be needed in the interim.
Problem
When ADP config keys are propagated to the Core Agent (e.g. via PRs like datadog-agent#51390), the default values defined in ADP
config.rsand in the Core Agentcommon_settings.gocan drift silently.In practice, ADP's defaults are dead code — the Core Agent always propagates its own defaults to ADP at runtime. But this creates a risk: developers may set a default in ADP and assume it's the customer-facing value, neglecting to propagate changes (or new defaults) to the Core Agent.
Related: #1649
Options considered
Option 1 — Remove defaults from ADP; rely entirely on Core Agent defaults
Simple to implement, but not fully viable: Rust's type system and serde require default values to be provided even when they'll never be used in practice.
Option 2 — ADP generates an artifact that Core Agent consumes to determine defaults
Keeps config definition close to the source of truth. Theoretically best, but requires new infrastructure to "dump" ADP defaults in a form the Core Agent can ingest. No such machinery exists today.
Option 3 — Tests that compare ADP and Core Agent default configs
Conceptually simpler than option 2. Could work by default-constructing Saluki structs and comparing them against schema defaults. Also requires infrastructure that doesn't yet exist.
Current thinking
Options 2 and 3 are both viable long-term solutions but require upfront investment to build comparison/export machinery. A process bandaid (e.g. a checklist or PR template reminder to propagate default changes to the Core Agent) may be needed in the interim.