sentry-javascript: [Bug]

I got around to digging deeper into this, and I think I found the source of the problem.

Where does “unlabeled event” come from?

<unlabeled event> is not something that users are passing, nor is it something that Raven applies. Where does it come from?

The answer is the Sentry server:

    def get_metadata(self):
        # See GH-3248
        message_interface = self.data.get(
            'sentry.interfaces.Message', {
                'message': self.data.get('message', ''),
            }
        )
        message = strip(message_interface.get('formatted', message_interface['message']))
        if not message:
            title = '<unlabeled event>'
        else:
            title = truncatechars(message.splitlines()[0], 100)
        return {
            'title': title,
        }

https://github.com/getsentry/sentry/blob/96bc1c63df5ec73fe12c136ada11561bf52f1ec9/src/sentry/eventtypes/base.py#L38

When handling a DefaultEvent object, Sentry attempts to get the “sentry.interfaces.Message” property (unsuccessfully) and falls back to the default value: { 'message': self.data.get('message', '') }

Which in turn evaluates to: { ‘message': ‘’ }

So message_interface is assigned to this object, and on line 36, message is assigned to message_interface[‘message’] — an empty string!

In the conditional on line 37, the empty string evaluates to false and title is assigned to our old friend, <unlabeled event>.

TL;DR — The DefaultEvent is lacking both of the following properties: sentry.interfaces.Message and message. So Sentry uses a stand-in value as the title: <unlabeled event>

There’s an error while processing this event. Why?

All unlabeled event errors appear alongside the same message: “There was 1 error encountered while processing this event”.

I believe this is the line responsible for adding the processing error.

The code appears to be casting each property (environment, breadcrumbs, exception, etc.) to a specific format. When the cast fails, it adds a processing error.

What happens next is highly interesting: The raw ‘message’ is coerced to the Sentry message interface:

        # raw 'message' is coerced to the Message interface, as its used for pure index of
        # searchable strings. If both a raw 'message' and a Message interface exist, try and
        # add the former as the 'formatted' attribute of the latter.
        # See GH-3248
        msg_str = data.pop('message', None)
        if msg_str:
            msg_if = data.setdefault('sentry.interfaces.Message', {'message': msg_str})
            if msg_if.get('message') != msg_str:
                msg_if.setdefault('formatted', msg_str)

If the message property is missing, it defaults to None, and msg_str becomes falsy. If msg_str is falsy, the sentry.interfaces.Message and formatted properties are never assigned to msg_if. As we saw at the beginning of this post, these properties are necessary to prevent title from being assigned to <unlabeled event>.

Hypothesis

Raven is sending a bad message object to the Sentry server. Specifically, it is missing the message property — or the message property is a falsy value, such as an empty string.

My guess is that somewhere in the captureException function (here), captureMessage is being passed an empty string for the msg param. Unfortunately, I can’t figure out which if statement the error falls into because don’t have access to the original error object —and I don’t know how to reproduce it.

Solution

We need to make sure to call captureMessage with a good msg param. In other words, we should not be passing it an empty string.

captureMessage is being called within captureException, so it looks like there’s an error type (or object shape) that we are not accounting for there.

Released as 3.26.3. Would appreciate a feedback with everyone’s findings.

Hey, we are aware of this and updating our react-native SDK to fix this, stay tuned.

After some research, I found that ways to trigger this issue are:

captureException('');
captureMessage('');
Raven.wrap(function () {
  throw '';
});

to trigger the exact issue, including mentioned server validation notification, throw '', but it has to bubble up to the global on-error handler.

I’m working on the solution.

We’re also getting this frequently on React Native

@kamilogorek - We have just upgraded from 3.9.1 to 4.4.1 and started to see <unlabeled event> entries, is there a regression here? We didn’t have any prior to updating.

@kamilogorek Any update? This represents a huge number of our inbound exceptions and it’s hard for us to ignore it given we don’t know if it masks real issues or not.

I’m happy to report that upgrading to the latest version of sentry-react-native (1.3.0) seems to have fixed this issue: (or we fixed something unknowingly in our code…)

We’re still seeing this on our React-Native app even after upgrading to the latest version, getting between 3k and 10k events a day which is eating up a lot of our quota. Is there a way to investigate in more detail?

I’m still seeing a few in 4.4.2, but only from Edge 18. I just updated to 4.6.3, let’s see if this changes anything…

@justinappler @andrew-dixon 4.4.2 should fix the issue.

unlabeled event has totally dropped off for us. Thanks!

@kamilogorek Here’s the one we’re seeing: https://sentry.io/crunchbase/client-app-v3-production/issues/364876156/?query=is:unresolved timesSeen:>5

Still seeing this hundreds, sometimes thousands of times per hour but we can’t hide it because don’t know if its a real issue or noise.