Skip to content
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

Open
rominf opened this issue Jul 19, 2024 · 1 comment · May be fixed by #3313
Open

Comments

@rominf
Copy link
Contributor

rominf commented Jul 19, 2024

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):

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
pip install \
  -r requirements-devenv.txt \
  pytest-django \
  psycopg2-binary \
  -e .[django]
export SENTRY_PYTHON_TEST_POSTGRES_USER=sentry
export SENTRY_PYTHON_TEST_POSTGRES_PASSWORD=sentry
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):

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
export SENTRY_PYTHON_TEST_POSTGRES_USER=sentry
export SENTRY_PYTHON_TEST_POSTGRES_PASSWORD=sentry
pytest tests/integrations/django/test_db_query_data.py \
  -k test_query_source_with_in_app_include  # FAIL

Expected Result

The behavior of in_app_include in add_query_source is consistent. Test pass.

Actual Result

The behavior of in_app_include in add_query_source is inconsistent. Test fails.

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.
@szokeasaurusrex
Copy link
Member

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
Labels
None yet
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

2 participants