refactor: move constants out of internal.constants#18964
Conversation
Circular import analysis
|
Codeowners resolved as |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b157a98c65
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
|
BenchmarksBenchmark execution time: 2026-07-11 00:07:08 Comparing candidate commit b1d7f04 in PR branch Found 0 performance improvements and 1 performance regressions! Performance is the same for 621 metrics, 10 unstable metrics. scenario:iastaspectsospath-ospathbasename_aspect
|
…ace/constants, or propagation/_constants depending on what units import them
There was a problem hiding this comment.
More details
Static analysis and adversarial constant-value tests confirm all 70+ constants were correctly relocated — values unchanged, no stale imports from ddtrace.internal.constants, new constants files are import-free (eliminating any circular-import risk), and every consumer (production + tests) now points to the new module path. The removed SPAN_API_OPENTRACING was dead code with zero callers.
📊 Validated against 12 scenarios · Open Bits AI session
🤖 Datadog Autotest · Commit c423a5c · What is Autotest? · Any feedback? Reach out in #autotest
KowalskiThomas
left a comment
There was a problem hiding this comment.
LGTM for Profiling.
Description
This change relocates many constant definitions from
ddtrace.internal.constants. For each constant, the destination was chosen based on the current set of dependent modules. Examples:ddtrace.internal.utils.constantsddtrace.propagation._constantsddtrace.internal.utils.constantsddtrace.contrib.internal._constantsThis approach reduces coupling by shrinking the widely-shared
internalmodule slightly.This change doesn't make any attempt to remove knowledge of external concepts from modules. For example,
ddtrace.internal.utils.httpcurrently knows about the concepts of sampling and span tags via its import ofSAMPLING_DECISION_TRACE_TAG_KEY, but it ideally would not. Such abstraction leakage will be addressed in a future change.Testing
No functional changes are expected