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.
If stephend is getting tracebacks for some, but not all errors, then it is a code issue.
Assignee: jdow → nobody
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).
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.
Austin - can you commit what you've done (as reference above)? Thanks
(In reply to comment #4) As I recall, this was all config in settings_local.py, so nothing to commit.
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?
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?)
(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.
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
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.
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?
Well i meant that it's not breaking the application - itll be done on monday so will be in the launch.
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.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 656128
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.