Default symbol_database.enabled to dynamic_instrumentation.enabled

[p-datadog]

Summary

Makes symbol_database.enabled default to the value of dynamic_instrumentation.enabled instead of a fixed boolean.

• DI on, env unset → symbol database upload is on by default
• DI off, env unset → symbol database upload is off by default
• DD_SYMBOL_DATABASE_UPLOAD_ENABLED or explicit c.symbol_database.enabled = … continue to override via the existing precedence chain

This replaces the unconditional true default that #5818 was reverted to. The config DSL's o.default { … } block is evaluated lazily on first get (see Datadog::Core::Configuration::Option#default_value), so the value is taken from whatever DI is configured to at the time symbol_database.enabled is first read — which in practice is Component.build, after user Datadog.configure blocks and env vars have been applied.

Precedent for this pattern: lib/datadog/tracing/contrib/redis/configuration/settings.rb and several other contrib settings use the same o.default do … end shape.

Changes

• lib/datadog/symbol_database/configuration.rb: replace o.default true with o.default { Datadog.configuration.dynamic_instrumentation.enabled }; update the comment block.
• spec/datadog/symbol_database/configuration_spec.rb: drop the env-unset row from the env-var table (its value now depends on DI, which the env table doesn't model). Add a dedicated context that asserts both branches and that the env var still wins.
• docs/GettingStarted.md: default column now reads "Tracks DD_DYNAMIC_INSTRUMENTATION_ENABLED" / "Tracks c.dynamic_instrumentation.enabled".

Change log entry

Yes. Dynamic Instrumentation: Symbol Database upload now defaults to the value of dynamic_instrumentation.enabled instead of a fixed default; set DD_SYMBOL_DATABASE_UPLOAD_ENABLED to override.

Test plan

• bundle exec rspec spec/datadog/symbol_database/ — 331 examples, 0 failures

[dd-octo-sts]

Thank you for updating Change log entry section 👏

^{Visited at: 2026-05-28 00:18:30 UTC}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c297bba664

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[datadog-official]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 94.74%
• Overall Coverage: 90.02% (-0.03%)

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

[dd-octo-sts]

Typing analysis

Note: Ignored files are excluded from the next sections.

steep:ignore comments

This PR introduces 1 steep:ignore comment, and clears 1 steep:ignore comment.

steep:ignore comments (+1-1)

❌ Introduced:

lib/datadog/symbol_database/component.rb:575

✅ Cleared:

lib/datadog/symbol_database/component.rb:573

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-06-25 15:22:30

Comparing candidate commit 888f78d in PR branch revert-5818-claude/symdb-default-off with baseline commit 75ccdd1 in branch master.

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 ----------------------------------'

[ivoanjo]

So how does this interact with #5525 ? Specifically, does this mean that symbol database will get enabled if DI gets enabled (via remote configuration or local config) OR is there any situation where symbol database gets enabled for existing customers not using DI?

[p-datadog]

@ivoanjo SymDB will be enabled by default if DI is enabled, via either of the routes (local configuration via env var or implicit enablement via RC). The reason is that, from customer's point of view, SymDB is needed to make DI UI actually work/be usable.

SymDB has independent toggles and may be turned off or on explicitly (via env var, etc.) regardless of DI state. So, a customer may turn on SymDB while leaving DI off. I am unaware of any guidance instructing customers to do this presently but this might be a use case that materializes in the future (AI-adjacent products/tooling would be my guess).

[ivoanjo]

I am unaware of any guidance instructing customers to do this presently but this might be a use case that materializes in the future (AI-adjacent products/tooling would be my guess).

Got it -- I have no concerns with customers that opt-into the feature (even when it's not being used); although we could explore some kind of warning that this configuration is not recommended.

So just to be extra sure: for customers using right now only combinations of tracing/profiling/appsec and not going into DI in the UX, are they guaranteed that SymDB will not be turned on? This is the case I want to make sure we don't impact such customers.

[p-datadog]

Yes SymDB will be off in those cases. SymDB is enabled via user actions only: either env var set or user turning Live Debugger on in UI.

[ivoanjo]

Ack, perfect, I think that's a great compromise 🙏