Use `request.path_info` to create Django transaction name

[OutOfFocus4]

Currently, the Django integration creates a transaction from the request URL by calling LEGACY_RESOLVER.resolve(request.path). This transforms URLS such as /test/1/ into /test/{pk}/.

However, if the Django application is served from a non-root path, such as /django/, request.path becomes /django/test/1/. Django only processes the /test/1/ part, which is accessible in request.path_info, but the transaction becomes /django/test/1/.

To demonstrate this, I created a new Django project and added the setting FORCE_SCRIPT_NAME = "/test" to settings.py.
I then created the following view:

from django.http.response import JsonResponse

from sentry_sdk.integrations.django.transactions import LEGACY_RESOLVER


def show_example(request, *args, **kwargs):
    return JsonResponse(
        {
            "current": LEGACY_RESOLVER.resolve(request.path),
            "correct": LEGACY_RESOLVER.resolve(request.path_info),
        }
    )

I added

path('<int:pk>/<var>/', views.show_example)

to the urlpatterns, then executed the runserver management command.

Here is the output of curl http://localhost:8000/1/@/:

{"current": "/test/1/@/", "correct": "/{pk}/{var}/"}

[untitaker]

Honestly I am not sure which one is better? Is it just that having a prefix is annoying to you? You can always set the transaction name manually: https://docs.sentry.io/platforms/python/enriching-events/transaction-name/

[OutOfFocus4]

The resolver is supposed to automatically create transaction names from the URL so that (for example) /test/1/test/ and /test/2/other/ are grouped together as /{pk}/{var}/ for error and performance tracking purposes. What I find annoying is that this process doesn't work if the Django application is accessed at a non-root path, which I assume isn't an uncommon setup.

I used FORCE_SCRIPT_NAME in my example, but I first noticed this problem occurring when using Apache with mod_wsgi. When using WSGIScriptAlias other than /, the SDK doesn't automatically group transactions, and I find it hard to believe that the resolver is only intended to group transactions in cases where the Django application can be accessed at /.

[untitaker]

Ah I missed the example at the bottom! Yes so basically there's no placeholder variables in your transaction names, makes sense!