-
Notifications
You must be signed in to change notification settings - Fork 447
fix(di): dynamic function discovery fallback #13947
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
We implement a dynamic function discovery fallback when the function-from-code resolution via the GC fails. This can happen if the target application has interacted with the GC, e.g. by freezing it at a time that will prevent the current discovery from being able to resolve the function from the referenced code object.
e9ca96c
to
e42f5ac
Compare
Bootstrap import analysisComparison of import times between this PR and base. SummaryThe average import time from this PR is: 286 ± 6 ms. The average import time from base is: 297 ± 6 ms. The import time difference between this PR and base is: -11.3 ± 0.3 ms. Import time breakdownThe following import paths have grown:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR implements a dynamic fallback for function resolution when the GC-based lookup fails and updates the discovery logic to use it.
- Adds a private
_resolve_pair
method that first triespair.resolve()
and, onValueError
, walks the module’s attributes to find the function. - Updates
by_name
to call_resolve_pair
for both direct and name-index lookups. - Includes a release note entry for the new fallback behavior.
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
File | Description |
---|---|
releasenotes/notes/fix-di-dynamic-discovery-fallback-3a5623e18584cd79.yaml | Adds a release note about the dynamic function discovery fallback. |
ddtrace/debugging/_function/discovery.py | Introduces _resolve_pair and refactors by_name to leverage the fallback. |
BenchmarksBenchmark execution time: 2025-07-11 11:15:21 Comparing candidate commit 5f6c000 in PR branch Found 0 performance improvements and 2 performance regressions! Performance is the same for 546 metrics, 2 unstable metrics. scenario:iastaspects-replace_aspect
scenario:telemetryaddmetric-1-distribution-metric-1-times
|
We implement a dynamic function discovery fallback when the function-from-code resolution via the GC fails. This can happen if the target application has interacted with the GC, e.g. by freezing it at a time that will prevent the current discovery from being able to resolve the function from the referenced code object. ## Testing Strategy The original issue was reproducible with a local deployment of [synapse](https://github.com/element-hq/synapse). The investigation led to the conclusion that the issue was caused by the way the application interacts with the GC https://github.com/element-hq/synapse/blob/1dc29563c1504a2523e467aa7bef6a7ac05cc60c/synapse/app/_base.py#L623C1-L629C35. Commenting out these lines makes the issue disappear. We have tested the fix against the unmodified application to verify that the proposed fix works. Refs: [DYNIS-28](https://datadoghq.atlassian.net/browse/DYNIS-28) ## Checklist - [x] PR author has checked that all the criteria below are met - The PR description includes an overview of the change - The PR description articulates the motivation for the change - The change includes tests OR the PR description describes a testing strategy - The PR description notes risks associated with the change, if any - Newly-added code is easy to change - The change follows the [library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) - The change includes or references documentation updates if necessary - Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) ## Reviewer Checklist - [x] Reviewer has checked that all the criteria below are met - Title is accurate - All changes are related to the pull request's stated goal - Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - Testing strategy adequately addresses listed risks - Newly-added code is easy to change - Release note makes sense to a user of the library - If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting) [DYNIS-28]: https://datadoghq.atlassian.net/browse/DYNIS-28?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ (cherry picked from commit b55f08f)
We implement a dynamic function discovery fallback when the function-from-code resolution via the GC fails. This can happen if the target application has interacted with the GC, e.g. by freezing it at a time that will prevent the current discovery from being able to resolve the function from the referenced code object. ## Testing Strategy The original issue was reproducible with a local deployment of [synapse](https://github.com/element-hq/synapse). The investigation led to the conclusion that the issue was caused by the way the application interacts with the GC https://github.com/element-hq/synapse/blob/1dc29563c1504a2523e467aa7bef6a7ac05cc60c/synapse/app/_base.py#L623C1-L629C35. Commenting out these lines makes the issue disappear. We have tested the fix against the unmodified application to verify that the proposed fix works. Refs: [DYNIS-28](https://datadoghq.atlassian.net/browse/DYNIS-28) ## Checklist - [x] PR author has checked that all the criteria below are met - The PR description includes an overview of the change - The PR description articulates the motivation for the change - The change includes tests OR the PR description describes a testing strategy - The PR description notes risks associated with the change, if any - Newly-added code is easy to change - The change follows the [library release note guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html) - The change includes or references documentation updates if necessary - Backport labels are set (if [applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)) ## Reviewer Checklist - [x] Reviewer has checked that all the criteria below are met - Title is accurate - All changes are related to the pull request's stated goal - Avoids breaking [API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces) changes - Testing strategy adequately addresses listed risks - Newly-added code is easy to change - Release note makes sense to a user of the library - If necessary, author has acknowledged and discussed the performance implications of this PR as reported in the benchmarks PR comment - Backport labels are set in a manner that is consistent with the [release branch maintenance policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting) [DYNIS-28]: https://datadoghq.atlassian.net/browse/DYNIS-28?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ (cherry picked from commit b55f08f)
We implement a dynamic function discovery fallback when the function-from-code resolution via the GC fails. This can happen if the target application has interacted with the GC, e.g. by freezing it at a time that will prevent the current discovery from being able to resolve the function from the referenced code object.
Testing Strategy
The original issue was reproducible with a local deployment of synapse. The investigation led to the conclusion that the issue was caused by the way the application interacts with the GC https://github.com/element-hq/synapse/blob/1dc29563c1504a2523e467aa7bef6a7ac05cc60c/synapse/app/_base.py#L623C1-L629C35. Commenting out these lines makes the issue disappear. We have tested the fix against the unmodified application to verify that the proposed fix works.
Refs: DYNIS-28
Checklist
Reviewer Checklist