Email full stack traces like in the debug error pages

[Anders Hovmöller]

The emails you get when you turn off debug mode are significantly less helpful than the nice html you get in the browser when the debug mode is on. I suggest simply sending an html mail with exactly the same stuff as in the debug page.

[Alex Gaynor]

Perhaps we could send a multipart email so people who want the plaintext tracebacks can still have them.

[Anders Hovmöller]

That's what the patch does actually. The plain text part of the email is unchanged.

[Mika Marttila]

Thanks for the patch. I'll see if I get it into our staging or even production server.

[Anders Hovmöller]

Is something happening with this issue? It's rather annoying to have to patch all my installations because this isn't in trunk.

[Russell Keith-Magee]

There are many reasons why this ticket hasn't progressed:

• The ticket hasn't been proposed for inclusion in milestone 1.2
• The patch doesn't apply to the current trunk.
• Your patch doesn't have documentation or tests.
• Your patch doesn't address an obvious API parity issue - ensuring that mail_managers should also have a html_message argument.
• Your patch doesn't address the fact that the rendering of complex HTML emails is notoriously unreliable. Sending an error email to Gmail, for example, results in almost an unreadable message.

I completely agree that there is plenty of scope to improve the error emails - but this patch isn't there yet (and given the timeframe before the 1.2 feature freeze, I'm going to guess it won't make the cut).

The logging proposal (#12012) is also of interest here. Error handling is currently hard-coded to call mail_admins; with a fully integrated logging backend, it would be possible to configure an SMTP handler to send emails on certain error conditions. Logging won't make 1.2 either, but it's worth keeping this in mind because I intend to make logging a personal priority for 1.3.

[Rob Hudson]

Updated patch to apply against trunk, added docs and tests, and API parity

[Rob Hudson]

I've updated the original patch for this to cover most of Russell's points above. The patch currently applies against trunk, I added docs and doctests, the API matches mail_managers. I tested the HTML in Gmail and it actually looks decent -- the toggle "Local vars" don't work, but it's legible and relatively clean looking.

However, after all this, I think this might be a DDN. I can imagine some people prefer "text/plain" error e-mails and some people may prefer a full "text/html" error e-mail, and how do you accomodate both? Perhaps a solution would be to include more details in the "text/plain" error e-mails to get closer to the detail that the HTML debug pages have?

[Rob Hudson]

PS: Also, if the goal is to get the full traceback and error debug pages as you'd see when DEBUG=True, this is mostly a solved problem in 3rd party space with things like django-sentry and Arecibo.

[Russell Keith-Magee]

@robhudson; as long as both text/plain and text/html are transmitted, and text/plain is transmitted first, HTML/Text mail support should be able to be handled by any decent mail client. However, it would be nice to see the text support improved so that it contains the same data as the html mail.

There's also some interesting crossover with the #12012 logging proposal that is targeted for 1.3.

[cope360]

Replying to robhudson:

I've updated the original patch for this to cover most of Russell's points above. [...]

Rob, I see an error in your patch at line 104 of /django/core/mail/__init__.py. settings.ADMINS is used instead of settings.MANAGERS in mail_managers.

Thanks for the patch.

[Brodie Rao]

I've attached two patches for this feature.

The first patch cleans up the debug exception template so that pretty printed values retain their whitespace. The second patch is based on boxed's and robhudson's work but updated for Django 1.3 and with some minor improvements.

AdminEmailHandler has been updated to send out HTML emails, and ExceptionReporter has grown a new is_email keyword argument. If is_email is True, JS and Pastebin-related code is omitted from the template. If request is None, request-related info is also omitted.

I've included robhudson's doc updates, but we should probably also update the AdminEmailHandler section of docs/topics/logging.txt to mention this new behavior.

[Russell Keith-Magee]

(In [14844]) Fixed #10863 -- Added HTML support to mail_managers() and mail_admins(), and used this to provide more and prettier detail in error emails. Thanks to boxed for the suggestion, and to Rob Hudson and Brodie Rao for their work on the patch.

[Vlada Macek]

Later disabled by default for safety reasons. Related ticket: #15603

Personally I enable the HTML multipart like this:

LOGGING['handlers']['mail_admins']['include_html'] = True

Only enable if you know what you're doing (when you have safe mail path where unauthorized people can't read sensitive content).

[Jacob]

Milestone 1.3 deleted

[Cal Leeming]

Guys - thought I should throw something in. We have been using middleware combined with ReportBug() (see ​http://djangosnippets.org/snippets/2191/ ) which we wrote last year.

However, we had an issue where someone was able to DoS the server by triggering thousands of large debug emails, which flooded the mail server, and kept connections hanging.

As such - we implemented flood control via means of memcache (using cache backend).

I would *HIGHLY* suggest that this patch should include something similar before it is included in the core. (we can provide if necessary??)

But in all fairness, django debug emails should have this protection anyway - despite whether it is html or plain text (should this be raised as a separate ticket??).