Bread Crumbs showing data from other uWSGI requests

Hi Sentry Team,

We are running a Django application, with a uWSGI config of the following (Irrelevant data snipped):

[uwsgi]
project = gapi-layer-drf

base = /var/www
home = /opt/lib/virtualenvs/%(project)
chdir = /var/www/gapi-layer-drf/gapi

pythonpath = /var/www/gapi-layer-drf/gapi
module = gapi.wsgi

plugins-dir = /opt/uwsgi/uwsgi-2.0.13.1
plugins = python35

uid = www-data
gid = www-data

harakiri = 20
# thunder-lock is basically necessary with threading. Helps deal with the "thundering herd" problem.
thunder-lock = true

# memory-report is necessary if doing stats. Proper reporting of data.
memory-report = true
logto = /var/log/uwsgi/%(project).log
logfile-chown = www-data

master = true
processes = 5
threads = 5

# Hush uWSGI from IOError, SIGPIPE, etc.
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true

# Setup a socket, which is more secure and offers better performance than a network port.
socket = /tmp/%(project).sock
chmod-socket = 666
chown-socket = www-data

# Use vacuum to clean up when the service is stopped.
vacuum = true

We are using Django Rest Framework and a custom Exception Handler. Essentially, any exception is captured, transformed for the response, but also delivered to Sentry via the standard logging module. We are using Raven 5.32

The Bread Crumbs seem to work well for the most part, and the tail of the crumbs indeed shows the appropriate request that caused the exception. For example. Here’s the tail end of a crumb, with the exception/time:

Then, above that, I have more crumbs, that are generally hidden (but not always). The primary thing to note is the substantial time difference between the previous crumbs and these ones. Essentially, they are not part of the same request-response cycle (and knowing our system, I can confirm that. We’d never hit a booking while hitting the Flight Control backend within a single request)

So, quite an interesting bit for us. It’s not necessarily an issue, but it might confuse our developers (or even myself in a pre-coffee state) what’s going on with this request.

Anything else I can provide, please let me know. Happy to help. Thank you!

[mitsuhiko]

@danpalmer gunicorn is a different issue. If you are using gunicorn i don’t think breadcrumbs work properly yet unless something patches threading.local. Not sure if gunicorn does that.

[akx]

Hmm, if it helps, it looks like these leaky breadcrumbs maybe don’t occur for exceptions, only for logging output. Our logging config is (non-Raven/Sentry things cropped out)

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'root': {
        'level': 'INFO',
        'handlers': ['sentry'],
    },
    'filters': {
        'require_debug_false': {
            '()': 'django.utils.log.RequireDebugFalse',
        },
    },
    'handlers': {
        'sentry': {
            'level': 'WARNING',
            'class': 'raven.contrib.django.raven_compat.handlers.SentryHandler',
            'filters': ['require_debug_false'],
        },
    },
    'loggers': {
        'raven': {
            'level': 'WARNING',
            'handlers': ['console'],
            'propagate': False,
        },
        'sentry.errors': {
            'level': 'DEBUG',
            'handlers': ['console'],
            'propagate': False,
        },
    }
}