Sentry keeps returning nonexistent incident id's

Question

We have a django project. We use Sentry for collecting info on HTTP 500 errors.

Sentry has an option to add incident information to request header, so you can handle it in your app.

So, we have a mixin for tastypie that looks like that:

class Sentry500Mixin(object):
def _handle_500(self, request, exception):

    if not isinstance(exception, TastypieError) and not settings.DEBUG:
        sentry_exception_handler(request=request)
        data = {
            'error_message': 'Sorry, this request could not be processed.',
            'incident': getattr(request, 'sentry', None)
        }
        return self.error_response(request, data, response_class=HttpApplicationError)

    else:
        return super(Sentry500Mixin, self)._handle_500(request, exception)

When a 500 error occurs we get responses like this:

 {"error_message": "Sorry, this request could not be processed.", 
"incident": {"id": "3459b30f87ea4116a0a2855be576bbb3", "project_id": "5"}}

The thing is that if you take this incident id and go to Sentry, there is a good chance that there will be no incident with this id. And no incident that look like this one. I am sure that I am checking the right project and if the incident was not created, logically, Sentry could not return you an ID, but it did.

Any help and ideas are much appreciated. Thanks.

Answer 1

As @erik-e explained in a comment, event_id is generated on the client.

UDP protocol has no guarantees.

Are you using the UDP protocol? If you are, the event_id does not necessarily map to an actual event in Sentry. The router/switch/network equipment may have lost your packet. With UDP there are no guarantees w.r.t delivery, ordering, or duplicate packets.

I am assuming the HTTP/HTTPS protocols for sentry are over TCP.

Solutions:

• double check firewall rules,
• try out other protocols and make sure it is not a problem with the sentry server.

Why use UDP then?

Some reasons commonly put forward:

• no handshake = it is faster,
• no connection = no problem if connection was to break (e.g. reboot of sentry server).