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

VERIFIED DUPLICATE of bug 656128

Status

Websites
markup.mozilla.org
--
critical
VERIFIED DUPLICATE of bug 656128
7 years ago
7 years ago

People

(Reporter: stephend, Assigned: brez)

Tracking

unspecified
Dependency tree / graph

Details

(URL)

(Reporter)

Description

7 years ago
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.
Blocks: 628811
Assignee: nobody → jdow

Comment 1

7 years ago
If stephend is getting tracebacks for some, but not all errors, then it is a code issue.
Assignee: jdow → nobody
(Reporter)

Updated

7 years ago
Blocks: 656128
(Reporter)

Comment 2

7 years ago
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

7 years ago
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.
(Assignee)

Updated

7 years ago
Assignee: nobody → jbresnik
(Assignee)

Comment 4

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

Comment 5

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

Comment 6

7 years ago
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?
(Reporter)

Comment 7

7 years ago
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

7 years ago
(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.
Target Milestone: 1.0 → 1.1
(Assignee)

Comment 9

7 years ago
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
(Assignee)

Comment 10

7 years ago
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?
(Assignee)

Comment 12

7 years ago
Well i meant that it's not breaking the application - itll be done on monday so will be in the launch.
(Assignee)

Comment 13

7 years ago
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: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 656128
thx brez
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.