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

Django: Record status and http.status_code on exception #1257

Merged
merged 2 commits into from Oct 21, 2020

Conversation

owais
Copy link
Contributor

@owais owais commented Oct 19, 2020

Description

Update Django instrumentation to record http.status_code and span status on exception.

Type of change

Please delete options that are not relevant.

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

  • Updated unit test

Checklist:

  • Followed the style guidelines of this project
  • Changelogs have been updated
  • Unit tests have been added
  • Documentation has been updated

@owais owais requested a review from a team as a code owner October 19, 2020 08:24
@owais owais requested review from codeboten and ocelotl and removed request for a team October 19, 2020 08:24
@owais owais force-pushed the django-exception-status-code branch 4 times, most recently from 722fbc4 to 405b7bb Compare October 19, 2020 12:09
@@ -184,13 +188,27 @@ def process_exception(self, request, exception):
return

if self._environ_activation_key in request.META.keys():
status_code = 500
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious, the status_code always 500?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Almost! There are some special cases where a user can raise an exception to return a specific HTTP error. I've re-implemented it in a much better way that doesn't assume status code.

@owais owais force-pushed the django-exception-status-code branch 5 times, most recently from 1a170d7 to b922711 Compare October 19, 2020 22:14
@owais owais force-pushed the django-exception-status-code branch from b922711 to 95a5b82 Compare October 19, 2020 22:38
@codeboten codeboten added the instrumentation Related to the instrumentation of third party libraries or frameworks label Oct 20, 2020
@lzchen
Copy link
Contributor

lzchen commented Oct 21, 2020

Just curious, what are your thoughts on the behavior of record_exception? Should an event be added to the span for exceptions in this case?

if self._excluded_urls.url_disabled(request.build_absolute_uri("?")):
return

if self._environ_activation_key in request.META.keys():
request.META[self._environ_activation_key].__exit__(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wasn't this behavior already implemented here? How does moving the logic to process_response change anything?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was but because we popped the activation key, process_response did not do anything. We recorded the exception but ignored the response meaning response code or metrics were not recorded for example. We could either duplicate the code here, take it out in a function and call from both places or just make the exception available to process_response so it can handle all cases.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right makes sense. Doesn't add_response_attributes already handle setting the status and http.status_code though?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, it does but without this change it was never executed in case of an exception so status_code (and other response attrs) were never set in case of an exception.

@owais
Copy link
Contributor Author

owais commented Oct 21, 2020

Just curious, what are your thoughts on the behavior of record_exception? Should an event be added to the span for exceptions in this case?

Yes, IMO this should definitely record an event to log the exception.

@lzchen
Copy link
Contributor

lzchen commented Oct 21, 2020

@owais

Yes, IMO this should definitely record an event to log the exception.

Yeah, i'll bring it up during the SIG meeting. Might be more complicated than it seems.

Copy link
Contributor

@codeboten codeboten left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@codeboten codeboten merged commit 9642b6d into open-telemetry:master Oct 21, 2020
@owais owais deleted the django-exception-status-code branch October 21, 2020 16:21
srikanthccv pushed a commit to srikanthccv/opentelemetry-python that referenced this pull request Nov 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
instrumentation Related to the instrumentation of third party libraries or frameworks
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants