fix(tracing): fix logic for setting in_app flag
#1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rominf
force-pushed
the
rominf-tracing-fix-logic-in_app
branch
3 times, most recently
from
2568b9c to
37f5dce
Compare
Make sure our breadcrumbs are sorted by timestamp before sending to Sentry. Fixes getsentry#3306
Adjust docstrings of all non-deprecated functions which take an `instrumenter` parameter to state that `instrumenter` is only meant to be used by the SDK, and that it is deprecated for client code. The docstrings also inform users that `instrumenter` will be removed in the next major release.
rominf
force-pushed
the
rominf-tracing-fix-logic-in_app
branch
from
37f5dce to
2d74969
Compare
…t root When packages added in `in_app_include` are installed to a location outside of the project root directory, span from those packages are not extended with OTel compatible source code information. Cases include running Python from virtualenv created outside of the project root directory or Python packages installed into the system using package managers. This results in an inconsistency: spans from the same project are be different, depending on the deployment method. The change extends `test_query_source_with_in_app_include` to test the simulation of Django installed outside of the project root. The steps to manually reproduce the issue are as follows (case: a virtual environment created outside of the project root): ```bash docker run --replace --rm --detach \ --name sentry-postgres \ --env POSTGRES_USER=sentry \ --env POSTGRES_PASSWORD=sentry \ --publish 5432:5432 \ postgres distrobox create \ --image ubuntu:24.04 \ --name sentry-test-in_app_include-venv distrobox enter sentry-test-in_app_include-venv python3 -m venv /tmp/.venv-test-in_app_include source /tmp/.venv-test-in_app_include/bin/activate pytest tests/integrations/django/test_db_query_data.py \ -k test_query_source_with_in_app_include # FAIL ``` The steps to manually reproduce the issue are as follows (case: Django is installed through system packages): ```bash docker run --replace --rm --detach \ --name sentry-postgres \ --env POSTGRES_USER=sentry \ --env POSTGRES_PASSWORD=sentry \ --publish 5432:5432 \ postgres distrobox create \ --image ubuntu:24.04 \ --name sentry-test-in_app_include-os distrobox enter sentry-test-in_app_include-os sudo apt install \ python3-django python3-pytest python3-pytest-cov \ python3-pytest-django python3-jsonschema python3-urllib3 \ python3-certifi python3-werkzeug python3-psycopg2 pytest tests/integrations/django/test_db_query_data.py \ -k test_query_source_with_in_app_include # FAIL ```
…root Fix: getsentry#3312 Previously, when packages added in `in_app_include` were installed to a location outside of the project root directory, span from those packages were not extended with OTel compatible source code information. Cases include running Python from virtualenv created outside of the project root directory or Python packages installed into the system using package managers. This resulted in an inconsistency: spans from the same project would be different, depending on the deployment method. In this change, the logic was slightly changed to avoid these discrepancies and conform to the requirements, described in the PR with better setting of in-app in stack frames: getsentry#1894 (comment). Note that the `_module_in_list` function returns `False` if `name` is `None` or `items` are falsy, hence extra check before function call can be omitted to simplify code.
rominf
force-pushed
the
rominf-tracing-fix-logic-in_app
branch
from
2d74969 to
a6921a5
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, in case packages added in
in_app_includewere installed into a location outside of the project root directory, stack frames from those packages were not marked asin_app. Cases include running Python from virtualenv, created outside of the project root directory, or Python packages installed into the system using package managers. This resultedin inconsistency: traces from the same project would have different
in_appflags depending on the deployment method.Steps to reproduce (virtualenv outside of project root):
Steps to reproduce (system packages):
In this change, the logic was slightly changed to avoid these discrepancies and conform to the requirements, described in the PR with
in_appflag introduction: getsentry#1894 (comment). Note that the_module_in_listfunction returnsFalseifnameisNone, hence extra check before function call can be omitted to simplify code.General Notes
Thank you for contributing to
sentry-python!Please add tests to validate your changes, and lint your code using
tox -e linters.Running the test suite on your PR might require maintainer approval. Some tests (AWS Lambda) additionally require a maintainer to add a special label to run and will fail if the label is not present.
For maintainers
Sensitive test suites require maintainer review to ensure that tests do not compromise our secrets. This review must be repeated after any code revisions.
Before running sensitive test suites, please carefully check the PR. Then, apply the
Trigger: tests using secretslabel. The label will be removed after any code changes to enforce our policy requiring maintainers to review all code revisions before running sensitive tests.