chore(symbol-db): refresh metadata after identity refresh

[litianningdatadog]

Stacked PRs:

• chore(runtime): add explicit identity refresh #19778
  • chore(flask): emit MicroVM request-starting event #19816
    • chore(http_server): emit pre-request web event #19817
    • feat(aws-lambda-microvm): refresh identity on Flask run hook #19825
    • chore(remoteconfig): refresh client identity on runtime refresh #19818
      • chore(appsec): tag spans with refreshed rc client id #19819
    • fix(tracer): isolate MicroVM identity refresh #19820
    • fix(telemetry): rebuild worker on identity refresh #19821
    • chore(runtime): refresh runtime metric identity and collector state #19822
    • chore(crashtracking): reconfigure after identity refresh #19823
    • 👉🏽 This PR chore(symbol-db): refresh metadata after identity refresh #19824

Description

Split from #19780.

Symbol DB metadata includes runtime identity. Refresh that metadata after runtime identity changes so Symbol DB events emitted after a MicroVM /run refresh use the new runtime id.

Testing

• scripts/lint format_check ddtrace/internal/symbol_db/symbols.py tests/internal/symbol_db/test_symbols.py
• git diff --check

Stack

Draft split branch. Stacked on #19816.

[datadog-prod-us1-3]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 0b9342c | Docs | View more details | Give us feedback!}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-08-23 22:26:19

Comparing candidate commit 26b013a in PR branch tianning.li/3-7-symbol-db-identity-refresh with baseline commit d59e112 in branch tianning.li/2-flask-web-request-starting-event.

📊 Benchmarking dashboard

Found 0 performance improvements and 11 performance regressions! Performance is the same for 610 metrics, 10 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 ----------------------------------'

scenario:httppropagationextract-wsgi_valid_headers_all

• 🟥 execution_time [+395.768ns; +462.411ns] or [+7.202%; +8.414%]

scenario:httppropagationinject-ids_only

• 🟥 execution_time [+1.956µs; +2.154µs] or [+10.195%; +11.225%]

scenario:iastaspects-add_aspect

• 🟥 execution_time [+15.692µs; +18.816µs] or [+15.427%; +18.497%]

scenario:iastaspects-join_aspect

• 🟥 execution_time [+46.896µs; +51.348µs] or [+22.140%; +24.242%]

scenario:iastaspects-ljust_noaspect

• 🟥 execution_time [+61.934µs; +65.922µs] or [+21.688%; +23.085%]

scenario:iastaspects-title_aspect

• 🟥 execution_time [+60.649µs; +66.587µs] or [+22.519%; +24.723%]

scenario:iastaspectsospath-ospathbasename_aspect

• 🟥 execution_time [+142.108µs; +149.038µs] or [+34.747%; +36.442%]

scenario:iastaspectssplit-rsplit_aspect

• 🟥 execution_time [+18.653µs; +21.930µs] or [+12.928%; +15.199%]

scenario:span-start

• 🟥 execution_time [+1.346ms; +1.505ms] or [+8.858%; +9.910%]

scenario:telemetryaddmetric-1-count-metric-1-times

• 🟥 execution_time [+427.897ns; +477.933ns] or [+15.884%; +17.741%]

scenario:tracer-small

• 🟥 execution_time [+27.479µs; +29.398µs] or [+8.154%; +8.723%]

Unstable benchmarks

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

scenario:coreapiscenario-context_with_data_listeners

• unstable execution_time [-667.684ns; +815.879ns] or [-6.050%; +7.393%]

scenario:coreapiscenario-core_dispatch_1_listener

• unstable execution_time [-35.575ns; +30.447ns] or [-5.797%; +4.961%]

scenario:coreapiscenario-core_dispatch_50_listeners

• unstable execution_time [-1664.037ns; +1666.709ns] or [-9.718%; +9.733%]

scenario:coreapiscenario-core_dispatch_exception_listeners

• unstable execution_time [-1216.680ns; +1229.665ns] or [-9.467%; +9.568%]

scenario:coreapiscenario-core_dispatch_listeners

• unstable execution_time [-337.450ns; +317.210ns] or [-9.158%; +8.608%]

scenario:coreapiscenario-core_dispatch_no_args_listeners

• unstable execution_time [-281.746ns; +227.377ns] or [-9.606%; +7.753%]

scenario:coreapiscenario-core_dispatch_with_results_1_listener

• unstable execution_time [-86.583ns; +59.350ns] or [-7.554%; +5.178%]

scenario:coreapiscenario-core_dispatch_with_results_50_listeners

• unstable execution_time [-3492.306ns; +4357.123ns] or [-8.731%; +10.893%]

scenario:coreapiscenario-core_dispatch_with_results_listeners

• unstable execution_time [-724.479ns; +839.686ns] or [-8.978%; +10.406%]

scenario:packagesupdateimporteddependencies-import_many_stdlib_cached

• unstable execution_time [-56.774µs; +63.180µs] or [-8.884%; +9.886%]

[cit-pr-commenter-54b7da]

Codeowners resolved as

Resolved from the full PR diff against tianning.li/2-flask-web-request-starting-event using the target branch CODEOWNERS file.
CODEOWNERS team requests not listed below are not required by the current file set.

ddtrace/internal/symbol_db/symbols.py                                   @DataDog/debugger-python
tests/internal/symbol_db/test_symbols.py                                @DataDog/debugger-python

[cit-pr-commenter-54b7da]

Dependency direction analysis

⚠️ Existing dependency direction violations

There are 250 dependency direction violations that already exist on the base branch and have not been changed by this PR.

Show existing violations (showing 5 of 250 highest severity)

ddtrace.internal.tracemethods -×-> ddtrace.trace  (internal-core -> product:tracing, score=135)
ddtrace.aiguard._api_client -×-> ddtrace.trace  (product:aiguard -> product:tracing, score=133)
ddtrace.debugging._exception.replay -×-> ddtrace.trace  (product:debugging -> product:tracing, score=133)
ddtrace.internal.opentelemetry.context -×-> ddtrace.trace  (product:opentelemetry -> product:tracing, score=133)
ddtrace.debugging._signal.tracing -×-> ddtrace.trace  (product:debugging -> product:tracing, score=133)

To see all violations, download the layers-base.json and layers-pr.json artifacts from this CI job and run:

uv run --script scripts/import-analysis/layers.py compare layers-base.json layers-pr.json

[cit-pr-commenter-54b7da]

Circular import analysis

⚠️ Existing circular imports

There are 3 circular imports that already exist on the base branch and have not been changed by this PR.

ddtrace.llmobs -> ddtrace.llmobs._evaluators -> ddtrace.llmobs._evaluators.format -> ddtrace.llmobs._experiment -> ddtrace.llmobs
ddtrace.errortracking._handled_exceptions.bytecode_injector -> ddtrace.errortracking._handled_exceptions.callbacks -> ddtrace.errortracking._handled_exceptions.collector -> ddtrace.errortracking._handled_exceptions.bytecode_reporting -> ddtrace.errortracking._handled_exceptions.bytecode_injector
ddtrace.appsec._asm_request_context -> ddtrace.appsec._iast._iast_request_context_base -> ddtrace.appsec._iast._iast_env -> ddtrace.appsec._iast.reporter -> ddtrace.appsec._exploit_prevention.stack_traces -> ddtrace.appsec._asm_request_context

[Copilot]

Pull request overview

Refreshes Symbol DB metadata after runtime identity changes so post-/run events use the current runtime ID.

Changes:

• Registers identity-change callbacks to rebuild upload metadata.
• Adds subprocess coverage for runtime and upload ID refreshes.
• Requires synchronization between explicit metadata refreshes and concurrent uploads.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Summary
tests/internal/symbol_db/test_symbols.py	Tests metadata updates after identity refresh.
ddtrace/internal/symbol_db/symbols.py	Refreshes Symbol DB metadata; concurrent refresh/upload access needs synchronization.

Suppressed comments (3)

ddtrace/internal/symbol_db/symbols.py:567

• ScopeContext can be constructed from the Remote Config poller's worker thread because Symbol DB is enabled lazily, while refresh_identity() can run on a request thread. on_runtime_id_change() adds to a global set while _refresh_runtime_id() iterates that set without synchronization; if installation overlaps a refresh, Python can raise RuntimeError: Set changed size during iteration, aborting the identity-refresh path. Make callback registration/dispatch synchronized, or register this callback before those operations can run concurrently.

        on_runtime_id_change(self._on_identity_refresh)

ddtrace/internal/symbol_db/symbols.py:567

• This stores a bound ScopeContext method in the process-global runtime callback set, but BaseModuleWatchdog.uninstall() does not remove it. The Symbol DB RC path can uninstall and reinstall the uploader, so each cycle leaves another retired context subscribed and retained; every later identity refresh then iterates and resets all of those stale contexts. Add callback unregistration to the lifecycle or register one stable callback that resolves the current uploader instance.

        on_runtime_id_change(self._on_identity_refresh)

ddtrace/internal/symbol_db/symbols.py:567

• on_runtime_id_change() is invoked by both refresh_identity() and the runtime module's post-fork hook. Since _reset_on_fork is still registered directly with forksafe above, every fork child now regenerates the upload ID and resets the batch counter twice: once through _on_identity_refresh and once through the direct fork hook. Keep a single reset path (or make the notifications distinguishable) so fork initialization does not perform duplicate state resets.

        on_runtime_id_change(self._on_identity_refresh)

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[litianningdatadog]

close it as it is out of the scope