fix(django): Do not patch resolver_match #842
Conversation
|
How does this change affect the timings of views? |
| from sentry_sdk.integrations.django import DjangoIntegration | ||
|
|
||
| old_resolve = URLResolver.resolve | ||
| old_make_view_atomic = BaseHandler.make_view_atomic |
There was a problem hiding this comment.
Is make_view_atomic available in every version of Django we support?
Had quick look at
https://github.com/django/django/blob/c1442e1192057a3bf14aecbaa1b713eee139eaff/django/core/handlers/base.py#L320
It is not so obvious that this is called for every view once.
There was a problem hiding this comment.
make_view_atomic is called in get_response_async and get_response which is where all requests go through. It is the only thing called directly before accessing the resolver match, so it should be pretty close with regard to how timings are done.
For example called here: https://github.com/django/django/blob/c1442e1192057a3bf14aecbaa1b713eee139eaff/django/core/handlers/base.py#L174
The impact on timing I could see is that the function wrapper is created at a different point in time, so it could shift instrumentation overhead to a different point in time and therefore move a small gap in teh trace somewhere else.
There was a problem hiding this comment.
It looks like it could possibly work 😄
Good job @untitaker! As a side-effect we got rid of the csrf_exempt exceptional handling, which is a nice bonus.
Fix #837