Query `code.filepath` points to irrelevant middleware function

[gggritso]

How do you use Sentry?

Sentry Saas (sentry.io)

Version

1.38.0

Steps to Reproduce

1. Enable query source collection of the Sentry application itself
2. Click on a transaction, find a database span longer than 500ms, and check its code.filepath property

Expected Result

The data path shows where the ORM call was made.

Actual Result

The path is of a middleware function that happens to be part of the stack trace. Is it possible to more precisely pinpoint the most relevant frame? e.g., see https://sentry.sentry.io/performance/sentry:6f96b1f00d1d4bcbaf7e22b48254833e/#span-a413698115897822 which shows a middleware that doesn't make the query. This is the case for all database spans at Sentry that go through this middleware, which is most of them.

[antonpirker]

The root cause is probably our logic finding the correct frame in the stacktrace is not good enough. We identified two areas where this is the case:

• when someone uses django rest framework
• when there is this middleware setup we have in sentry (desribed in the description above)

So we need to make our stack finding logic smarter. And maybe check for installed modules like Django, Django Restframework or SQLAlchemy to take this into consideration when walking the stack to find the correct frame.

This is the corrent logic: https://github.com/getsentry/sentry-python/blob/antonpirker/refactor-hub/sentry_sdk/tracing_utils.py#L195-L218

[sentrivana]

I've tested this with Django REST Framework and the frame located is correct, but the lineno is slightly off -- I believe this is due to DRF postponing the actual evaluation of the query (I assume). I don't see a way around that unless we want to try to come up with some sort of heuristic to search the frame for something that looks like a Django ORM call, but that feels flimsy.

Was this also the case in your tests with DRF @antonpirker @gggritso? The frame being correct, but not the lineno? Or was the frame itself picked incorrectly?

[gggritso]

@sentrivana from my poking around, I'm seeing an incorrect frame. For example, this query lists code.filepath as /getsentry/middleware/disallowed_organization.py but that middleware didn't make the function call. I'm trying to reproduce this locally so I can get you a stack trace but no luck so far!

[sentrivana]

Gotcha. It's probably a combination of multiple things (DRF + the middleware). I'm also still trying to repro.