fix(telemetry): tolerate malformed dist-info in get_distributions

[labbati]

Problem

ddtrace.internal.packages.get_distributions does strict metadata["name"] access. On environments where one installed dist has malformed METADATA (missing Name:, unparseable PKG-INFO) and missing-key access raises (importlib_metadata backport, -W error::DeprecationWarning, future Python), the call raises and @callonce caches the exception for the lifetime of the process.

Impact

The telemetry dependency tracker (added in #17593) calls get_distributions per imported module on every heartbeat, wrapped in try/except + log.debug(exc_info=True). Every call after the first re-raises the cached exception, producing a chained AttributeError/KeyError traceback per module per heartbeat per worker — customer reports of ~16 GiB of stderr per pytest CI job under uv venv --system-site-packages trace back to this.

The same bug exists, less loudly, in _package_for_root_module_mapping and the <3.10 _packages_distributions fallback: one bad dist collapses the whole mapping to None, silently breaking is_third_party / filename_to_package for the rest of the process.

Solution

Per-dist try/except in all three functions: skip malformed entries individually, return what could be parsed, warn once per bad dist (deduped via _BAD_DISTS_WARNED). The update_imported_dependencies shutdown-hardening guard from #17593 is unchanged — it still defends against shutdown-time iterator failures that can't be caught from inside get_distributions.

Verification: end-to-end against the customer reproducer (50 modules + one bad dist on path) — pre-fix logs 50 chained tracebacks, post-fix logs 0 (one diagnostic Skipping distribution warning). scripts/run-tests --venv 803a341 -- tests/internal/test_packages* → 7 passed.

Backport candidate to 4.8.x. Refs: #17593

Perf

While we added atry/except it is not generating a sigifnificant impact on python < 3.11, as the leading overhead comes from I/O

 ┌─────────┬──────────┬────────────┬─────────────────┐
 │ Python  │ plain    │ try/except │ Δ per iter      │
 ├─────────┼──────────┼────────────┼─────────────────┤
 │ 3.10.13 │ 26.39 ns │ 28.88 ns   │ +2.5 ns         │
 ├─────────┼──────────┼────────────┼─────────────────┤
 │ 3.11.8  │ 22.84 ns │ 23.30 ns   │ +0.5 ns (noise) │
 └─────────┴──────────┴────────────┴─────────────────┘

For get_distributions specifically: it's @callonce (runs once per worker) over ~150 dists and is
dominated by METADATA file I/O (~27 ms total on 3.10). The worst-case added cost is 2.5 ns × 150 ≈
0.4 µs, six orders of magnitude under the function's runtime — invisible in an end-to-end bench
against real importlib.metadata.distributions().

🤖 Generated with Claude Code

[cit-pr-commenter-54b7da]

Codeowners resolved as

ddtrace/internal/packages.py                                            @DataDog/apm-core-python
releasenotes/notes/fix-get-distributions-malformed-metadata-879c9025d81a0311.yaml  @DataDog/apm-python
tests/internal/test_packages_resilience.py                              @DataDog/apm-core-python

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-05-11 16:25:31

Comparing candidate commit c4023d3 in PR branch labbati/ddtrace-get-distributions-resilience with baseline commit 2a937b8 in branch main.

Found 0 performance improvements and 5 performance regressions! Performance is the same for 590 metrics, 4 unstable metrics.

scenario:iastaspects-index_aspect

• 🟥 execution_time [+12.918µs; +15.281µs] or [+10.391%; +12.291%]

scenario:iastaspects-stringio_aspect

• 🟥 execution_time [+637.380µs; +679.113µs] or [+16.517%; +17.599%]

scenario:iastaspectsospath-ospathbasename_aspect

• 🟥 execution_time [+88.780µs; +97.190µs] or [+21.064%; +23.060%]

scenario:span-start

• 🟥 execution_time [+1.328ms; +1.477ms] or [+8.540%; +9.501%]

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

• 🟥 execution_time [+194.613ns; +230.208ns] or [+9.312%; +11.015%]

[github-actions]

This change is marked for backport to 4.7 and it does not conflict with that branch.
The command used to test backporting was

git checkout 4.7 && git cherry-pick -x --mainline 1 c63b1b5fdb097348a7d66f4c8a57ed9002cb7517

[github-actions]

This change is marked for backport to 4.8 and it does not conflict with that branch.
The command used to test backporting was

git checkout 4.8 && git cherry-pick -x --mainline 1 c63b1b5fdb097348a7d66f4c8a57ed9002cb7517

[github-actions]

This change is marked for backport to 4.6 and it does not conflict with that branch.
The command used to test backporting was

git checkout 4.6 && git cherry-pick -x --mainline 1 c63b1b5fdb097348a7d66f4c8a57ed9002cb7517

[labbati]

/merge -p urgent

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-05-11 18:02:58 UTC ℹ️ Start processing command /merge -p urgent

---

2026-05-11 18:03:03 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in main is approximately 53m (p90).

---

2026-05-11 18:07:09 UTC ❌ MergeQueue: The build pipeline contains failing jobs for this merge request

Build pipeline has failing jobs for b9729cf:

• build linux: [amd64, cp314-cp314, v85383325-751efc0-musllinux_1_2_x86_64]

⚠️ Do NOT retry failed jobs directly (why?).

What to do next?

• Investigate the failures and when ready, re-add your pull request to the queue!
• If your PR checks are green, try to rebase/merge. It might be because the CI run is a bit old.
• Any question, go check the FAQ.

Details

Since those jobs are not marked as being allowed to fail, the pipeline will most likely fail.
Therefore, and to allow other builds to be processed, this merge request has been rejected and the pipeline got canceled.