django.utils.log.AdminEmailHandler won't include stack trace when django.server logs are propogated

[Wesley Ellis]

If I configure LOGGING such that logger has the propagate property set to True, the AdminEmail handler no longer contains a stack trace.

I can reproduce with the following changes to settings.py for a brand new django app here: ​https://github.com/wesleyjellis/django_bug/commit/3994f74b57ecdec95c91fc322a64ce08887de2cc

EMAIL_BACKEND = "django.core.mail.backends.console.EmailBackend"

ADMINS = [('Test', 'test@example.com')]

LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "handlers": {
        "console": {
            "level": "INFO",
            "class": "logging.StreamHandler",
        },
        "mail_admins": {
            "level": "ERROR",
            "class": "django.utils.log.AdminEmailHandler",
        },
    },
    "loggers": {
        "django": {"handlers": ["console", "mail_admins"], "level": "INFO",},
        "django.server": {
            "handlers": ["console"],
            "level": "INFO",
            "propagate": True, # If this is True, AdminEmailHandler gets a record where record.request is a socket
        },
    },
}

The stack trace seems to be coming from the technical_500 templates, but those templates don't include the stack frame if there is no request: ​https://github.com/django/django/blob/master/django/views/templates/technical_500.txt#L3

The request is set here: ​https://github.com/django/django/blob/master/django/utils/log.py#L9

But for some reason I don't understand, record.request is a socket object when propagate: True

I've attached the logs for both cases here: ​https://github.com/wesleyjellis/django_bug/commit/baa912ead8cc6f8dee1b6a69d6b5ff2cf133ef71

[Carlton Gibson]

Hi Wesley.

The django.server logger applies to the WSGI server infrastructure that powers the development runserver command. This is essentially a socket server, so when that logger adds self.request to the log record, it is adding the socket, not a Django request object that you're expecting. (I'm guessing this is why django.server does not propagate by default.) When propagating up to the django logger, and hitting the mail_admins handler, it's that that's logged.

The properly formatted report that is generated is coming from the django.request logger, which is used inside the request handling machinery (django/core/handlers) and which gets the, expected, Django request object.