[Django] #31780: Include the Python traceback in the debug-page footer as a HTML comment
Django
-------------------------------------+-------------------------------------
Reporter: Tom | Owner: nobody
Forbes |
Type: | Status: new
Uncategorized |
Component: | Version: master
Uncategorized | Keywords:
Severity: Normal | technical_500_response
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 1
UI/UX: 0 |
-------------------------------------+-------------------------------------
It would be very handy to include the traceback that triggered the Django
debug page inside a HTML comment in the footer of the page. Quite often
you might get a debug-page HTML output from tests or other places where it
is inconvenient to try and find the actual cause of the exception - you
have to page up through many kilobytes of HTML content to find the cause
of the exception.
If we can include just a raw Python traceback in the footer of the debug
page as a HTML comment then this will be immediately discoverable in such
situations. `print(html_response)` and `curl` would both show it without
needing any scrolling or grepping.
--
Ticket URL: <https://code.djangoproject.com/ticket/31780>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Uncategorized | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
technical_500_response | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
* type: Uncategorized => New feature
--
Ticket URL: <https://code.djangoproject.com/ticket/31780#comment:1>
Django
-------------------------------------+-------------------------------------
Component: Core (Other) | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
technical_500_response | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => wontfix
* component: Uncategorized => Core (Other)
Comment:
Thanks, I understand your intentions, but "raw" traceback is already
included in the ''"Copy-and-past-view"''. IMO we shouldn't add traceback
for the third time in the footer, it can be misleading and will make 500
responses even longer (I saw that you proposed adding it as a HTML
comment).
> ... you might get a debug-page HTML output from tests or other places
where it is inconvenient to try and find the actual cause of the exception
- you have to page up through many kilobytes of HTML content to find the
cause of the exception.
The technical 500 page is not really designed for tests. You can always
use a custom `500.html` for them.
--
Ticket URL: <https://code.djangoproject.com/ticket/31780#comment:3>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: closed
Component: Core (Other) | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
technical_500_response | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Tom Forbes):
I'd really like you to reconsider closing this. To put it in more general
terms: the #1 use case for the debug page is to locate the error that
caused the exception, and there are plenty of cases where you might have
the raw HTML rather than viewing it in a browser. Right now the debug page
is not helpful at all in this case.
It is indeed in the copy-paste view but that also involves grepping
through *large* volumes of HTML to find it. I don't think it's a problem
to include it in the footer, size doesn't matter for a debug page and the
key metric is "the time it takes you to find the cause of the error". I
cannot see how this does not help reduce that metric.
--
Ticket URL: <https://code.djangoproject.com/ticket/31780#comment:4>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: closed
Component: Core (Other) | Version: master
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
technical_500_response | Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 1 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Carlton Gibson):
Hi Tom.
I appreciate the pain in deciphering HTML in the middle of a failing test
case. In any case where you're able to `print(html_response)` you should
also be also to inspect
[https://docs.djangoproject.com/en/3.0/topics/testing/tools/#django.test.Response.exc_info
`exc_info`] which will also give you access to the exception (and the
traceback) directly.
(If the TestClient should annotate responses with **more info**, this
seems a much better way to go than, sorry-for-the-wording, littering the
500 template.)
Remember too, that you can set any Accepts header other than `text/html`
to get a plain text error response.
In the curl case, piping into less and using searching for "Traceback "
doesn't strike me as too burdensome...
I hope that makes sense.
--
Ticket URL: <https://code.djangoproject.com/ticket/31780#comment:5>