fix: report scalar remote configuration telemetry values

[bm1549]

What does this PR do?

Configuration-change telemetry now sends schema-safe primitive values.

• Header tags are reported as a comma-separated string.
• Sampling rules are reported as a JSON string.
• Sampling rates remain numeric.
• The remote configuration dispatcher reports the value that was applied, rather than the raw input.
• The telemetry event applies the same conversion as a final guard before serialization.

Startup telemetry keeps its existing string formatting.

Motivation:

Header tags and sampling rules could reach configuration-change telemetry as arrays or hashes. Those values do not match the telemetry intake schema, so intake rejects the request instead of storing any event in the batch.

Change log entry

Yes. Prevent runtime configuration telemetry from being rejected when header tags or sampling rules are updated remotely.

Additional Notes:

AI was used while implementing this change. I reviewed and understood the resulting code and tests.

A local app running 2.40.0-dev sent telemetry through Agent 7.81.2 to a test org. The test org credentials did not have permission to write APM Remote Configuration, so the live run could not deliver a configuration update or verify the stored scalar value. The same-window decoder query returned no configuration decoder failures.

How to test the change?

• Focused telemetry and remote configuration specs: 123 examples, 0 failures.
• bundle exec rake test:main: two matrix runs, each with 6,343 examples and 0 failures.
• Targeted StandardRB checks.
• Steep, missing-signature, and stale-signature checks.

[dd-octo-sts]

Typing analysis

Note: Ignored files are excluded from the next sections.

steep:ignore comments

This PR introduces 2 steep:ignore comments, and clears 2 steep:ignore comments.

steep:ignore comments (+2-2)

❌ Introduced:

lib/datadog/core/telemetry/event/app_started.rb:146
lib/datadog/core/telemetry/event/app_started.rb:152

✅ Cleared:

lib/datadog/core/telemetry/event/app_started.rb:145
lib/datadog/core/telemetry/event/app_started.rb:151

Untyped methods

This PR introduces 2 untyped methods and 2 partially typed methods, and clears 5 untyped methods and 2 partially typed methods. It increases the percentage of typed methods from 69.55% to 69.69% (+0.14%).

Untyped methods (+2-5)

❌ Introduced:

sig/datadog/core/telemetry/event/app_client_configuration_change.rbs:23
└── def ==: (untyped other) -> untyped
sig/datadog/core/telemetry/event/app_client_configuration_change.rbs:27
└── def hash: () -> untyped

✅ Cleared:

sig/datadog/core/telemetry/event/app_client_configuration_change.rbs:18
└── def payload: () -> { configuration: untyped }
sig/datadog/core/telemetry/event/app_client_configuration_change.rbs:22
└── def ==: (untyped other) -> untyped
sig/datadog/core/telemetry/event/app_client_configuration_change.rbs:26
└── def hash: () -> untyped
sig/datadog/tracing/configuration/dynamic.rbs:11
└── def call: (untyped tracing_header_tags) -> untyped
sig/datadog/tracing/configuration/dynamic.rbs:15
└── def call: (untyped tracing_sampling_rate) -> untyped

Partially typed methods (+2-2)

❌ Introduced:

sig/datadog/core/telemetry/event/app_client_configuration_change.rbs:31
└── def configuration_entry: (String name, untyped value, String origin, Integer seq_id) -> telemetry_configuration
sig/datadog/tracing/configuration/dynamic.rbs:22
└── def call: (Array[Hash[String, untyped]]? tracing_sampling_rules) -> Datadog::Core::Telemetry::Event::telemetry_value

✅ Cleared:

sig/datadog/core/telemetry/event/app_client_configuration_change.rbs:20
└── def configuration: () -> Array[Hash[Symbol, untyped]]
sig/datadog/tracing/configuration/dynamic.rbs:22
└── def call: (Array[Hash[String, untyped]] tracing_sampling_rules) -> void

Untyped other declarations

This PR introduces 1 partially typed other declaration, and clears 2 untyped other declarations. It increases the percentage of typed other declarations from 84.88% to 84.94% (+0.06%).

Untyped other declarations (+0-2)

✅ Cleared:

sig/datadog/core/telemetry/event/app_client_configuration_change.rbs:6
└── @changes: untyped
sig/datadog/core/telemetry/event/app_client_configuration_change.rbs:8
└── @origin: untyped

Partially typed other declarations (+1-0)

❌ Introduced:

sig/datadog/core/telemetry/event/app_client_configuration_change.rbs:6
└── type configuration_changes = Array[[String, untyped]] | Hash[String, untyped]

If you believe a method or an attribute is rightfully untyped or partially typed, you can add # untyped:accept on the line before the definition to remove it from the stats.

[datadog-prod-us1-4]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 63.16%
• Overall Coverage: 90.02% (-0.01%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: d595c67 | Docs | Datadog PR Page | Give us feedback!}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-07-30 03:16:42

Comparing candidate commit 50c0d9e in PR branch brian.marks/scalar-remote-config-telemetry with baseline commit 90f3c3c in branch master.

📊 Benchmarking dashboard

Found 0 performance improvements and 0 performance regressions! Performance is the same for 48 metrics, 1 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:tracing - trace.to_digest - Continue

• unstable throughput [-1000.189op/s; +2010.022op/s] or [-3.494%; +7.022%]