-
Notifications
You must be signed in to change notification settings - Fork 486
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
in_app_include
in add_query_source
works differently, depending on the package installation method
#3312
Comments
rominf
added a commit
to rominf/sentry-python
that referenced
this issue
Jul 19, 2024
…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
added a commit
to rominf/sentry-python
that referenced
this issue
Jul 19, 2024
…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.
Hi @rominf, thanks for reporting this issue and creating a PR! We will try to take a look sometime next week. |
rominf
added a commit
to rominf/sentry-python
that referenced
this issue
Jul 20, 2024
…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
added a commit
to rominf/sentry-python
that referenced
this issue
Jul 20, 2024
…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
added a commit
to rominf/sentry-python
that referenced
this issue
Jul 20, 2024
…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
added a commit
to rominf/sentry-python
that referenced
this issue
Jul 30, 2024
…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
added a commit
to rominf/sentry-python
that referenced
this issue
Aug 27, 2024
…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).
rominf
added a commit
to rominf/sentry-python
that referenced
this issue
Aug 27, 2024
…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).
rominf
added a commit
to rominf/sentry-python
that referenced
this issue
Aug 27, 2024
…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).
rominf
added a commit
to rominf/sentry-python
that referenced
this issue
Sep 5, 2024
…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).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
How do you use Sentry?
Self-hosted/on-premise
Version
master, also 2.7.1
Steps to Reproduce
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 steps to manually reproduce the issue are as follows (case: a virtual environment created outside of the project root):
The steps to manually reproduce the issue are as follows (case: Django is installed through system packages):
Expected Result
The behavior of
in_app_include
inadd_query_source
is consistent. Test pass.Actual Result
The behavior of
in_app_include
inadd_query_source
is inconsistent. Test fails.The text was updated successfully, but these errors were encountered: