656345 - Not receiving a Django traceback email for a certain 500 Internal Server Error

Status: VERIFIED DUPLICATE of bug 656128

(Websites Graveyard :: markup.mozilla.org, defect)

Description

[Stephen Donner [:stephend] Not actively reading bugmail]

Although I'm signed up for them (and getting them for other 500 Internal Server Errors), I'm not getting tracebacks emailed for the 500 when hitting https://markup-dev.allizom.org/en-US/#/linear/8CK9x.

It's critical that Dev/QA get all Django tracebacks; can we please investigate for 1.0?  Thanks.

Comment 1

[Justin Dow [:jabba]]

If stephend is getting tracebacks for some, but not all errors, then it is a code issue.

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

I've asked over in bug 656128 that we hold off on fixing that bug until we've had a chance to investigate this (as we'll need it for a reproducible case).

Comment 3

[Austin King [:ozten]]

Following the Django email error tips in
http://docs.djangoproject.com/en/dev/howto/error-reporting/
http://docs.djangoproject.com/en/dev/ref/settings/#email-backend
http://docs.djangoproject.com/en/dev/topics/email/#email-backends

I've got my local instance "sending" email to a local file. I tested by creating a syntax error and I get the stack trace.

If we can nail down Repro steps in Bug#656128, then we can diagnose why emails aren't sent.

Comment 4

[[:brez]]

Austin - can you commit what you've done (as reference above)?    Thanks

Comment 5

[Austin King [:ozten]]

(In reply to comment #4)
As I recall, this was all config in settings_local.py, so nothing to commit.

Comment 6

[Justin Dow [:jabba]]

I don't think so. Stephend is getting tracebacks for most, but not all 500 ISEs, which means that something in the code isn't consistent about traceback handling?

Comment 7

[Stephen Donner [:stephend] Not actively reading bugmail]

I just checked, and I got a traceback just now from comment 0's https://markup-dev.allizom.org/en-US/#/linear/8CK9x -- anybody else missing tracebacks, now?  (Wonder what changed?)

Comment 8

[Austin King [:ozten]]

(In reply to comment #6)
From a development perspective, the way to fix this is:
1) Get a data dump of -dev so a local env can be setup that way or
2) Document how to repro the issue in a clean env

#2 is a better process.

Once a local instance can repro the error, then the exact difference can be identified (by a developer) with a debugger or print statements.

Comment 9

[[:brez]]

Been working thru this on and off - issue is that it's set up probably but not behaving like its supposed to.. anyhow still working on it

Comment 10

[[:brez]]

Also note, while critical this should *not hold a launch its simply a matter of the log not sending errors to the admin when they occur.

Comment 11

[Matt Brandt [:mbrandt]]

I'm not persuaded that this shouldn't prevent a launch. What's the risk of a serious issue being masked by a lack of feedback if we're not receiving tracebacks?

I say this lovingly :) please persuade me. Help me understand the risks associated with not receiving this output?

Comment 12

[[:brez]]

Well i meant that it's not breaking the application - itll be done on monday so will be in the launch.

Comment 13

[[:brez]]

So turns out this is just a mishandled 404 (see https://bugzilla.mozilla.org/show_bug.cgi?id=656128 for comments on what happened) i.e. there is no stack trace because the 500 is generated by calling HttpResponseServerError and not actually an exception..  Fixing 656128 (doing now) will fix this as well. Closing for now as a duplicate since the real issue is with 656128.

Comment 14

[Matt Brandt [:mbrandt]]

thx brez