TL;DR: Our way of parsing named group regexes out of Django URL patterns is not ideal. If someone is using (Django 2.0+) <converter:parameter> path patterns, we can parse those directly without turning them into regexes first and potentially hitting our limitations there.

Background

When instrumenting Django for performance monitoring, the Sentry Python SDK will by default name the transactions based on the URL pattern rule that was used to serve the request.

There are two main ways of creating a URL pattern in Django: by using regexes in the rule directly, or (since Django 2.0) by using the custom <converter:parameter> syntax, like so:

urlpatterns = [
    path('articles/<int:year>/<int:month>/', views.month_archive),
]

These <converter:parameter> style patterns are also regexes in the background. Each of the converters defines its own regex (see e.g. the IntConverter) that is then used for matching URLs to the patterns.

The SDK is parsing both types of patterns with the aim of replacing all named groups with placeholders, so that e.g. the URL pattern above creates transactions with the name articles/{year}/{month}. To do this, the URL pattern is first turned into its regex form and then parsed with the RavenResolver.

This is not a problem with the default set of converters Django offers, but if folks define their own custom converters whose regexes don't play nice with our RavenResolver, we fail to extract the transaction name correctly. This can be prevented by parsing the original, simpler URL pattern instead without turning it into its regex form.

Note that this doesn't solve all transaction name problems as re_paths are still vulnerable, but it should make new-style paths work.

Closes #2446