Empty message in webhook event

[href]

Package + Version

• @sentry/browser

Version:

5.0.7

Description

The messages sent from Sentry-Javascript to our Zulip Chat Webhook contain no message, which is unhelpful because the Zulip integration is super bare-bones and without a message we cannot tell errors apart.

See https://github.com/zulip/zulip/blob/master/zerver/webhooks/sentry/view.py

This is a typical event that we receive through the webhook:

{
  "project_name": "Test",
  "message": "",
  "id": "981585759",
  "culprit": "?(/7da9c72a3b5f9e060b898ef7cd714b8a/common.bundle.js)",
  "project_slug": "foo-bar",
  "url": "https://sentry.io/organizations/....&referrer=webhooks_plugin",
  "level": "error",
  "triggering_rules": [
    "Send a notification for new events"
  ],
  "event": {
    ...
    "title": "ReferenceError: Can't find variable: test",
    ...
    }
}

As you can see the message is empty. This only occurs with sentry-javascript. In our sentry-python setup we always receive a message.

I'm tempted to write my own webhook handler, because there's clearly some useful information here (event.title would be a great alternative to message), but I do wonder why the message would be empty. Wouldn't it make sense for the message to contain some kind of string in any case?

Also, Is there some documentation about the webhook message format?

[href]

We've updated raven on Python from 6.6.0 to sentry_sdk 0.7.10 and now we're seeing the same problem there.

[HazAT]

I am looping @mitsuhiko do you have more insights maybe?

[HazAT]

@href Do you by any chance still know what was there before message was empty?
We changed this on the server so this has nothing to do with the SDKs.

[href]

I wouldn't know for a specific event, I only looked at the raw JSON when debugging this issue and noticed that the message was empty.

I looked at some older events that showed up correctly and I noticed that there is also a message in the the issue view at sentry.io. For example:

For the newer events, this is entirely absent. It seems to me that the message was produced from the exception or the breadcrumbs, maybe according to some heuristic.

If you can check this on the server, you can compare an older exception, generated a view days ago with raven on Python:
https://sentry.io/organizations/seantis-gmbh/issues/976059660

And a newer exception generated today with the latest Sentry SDK for Python:
https://sentry.io/organizations/seantis-gmbh/issues/982720355

If you can access these issues you'll see that for the newer one there is no message, even though it seems like that should be something that can be gathered from the exception.

Note that we do not capture any messages ourselves on either Javascript or Python, we simply capture the exceptions as they occur.

[untitaker]

@href The message you see from the raven-python SDK seems more like a logging message that happens when you do this:

try:
    raise OperationalError(...)
except:
    logger.exception("Error importing events")

I wonder if the code that captures the second exception you posted just looks differently, and e.g. calls capture_exception directly instead of going through a logger.

[untitaker]

An example for a sentry-sdk (=sentry.python) event that has message set: https://sentry.io/organizations/seantis-gmbh/issues/534351325/events/52525413028/

[href]

Your example is indeed one where we explicitly do set a logging exception as you demonstrate. As far as I know this is about the only code path where that happens.

For the others we only run capture_exception, which used to result in a message with Raven in Python, but does not anymore with the new SDK. Since the SDK brought some changes we did change some of our code, but it still essentially leaves the exception capturing to Sentry's code.

For the JS SDK we did not change anything but the import, but to be fair it stopped working before we changed from raven.js to the new SDK.

---

The question really boils down to this: Should the message always have some content, or not?

It seems like for at least a time this was the case. If it is expected behaviour that the message is empty at times, if no message was provided by the user, then this issue can be closed. Then it should be up to Zulip or our webhook-handler to get more specific information out of the event posted by Sentry.

[untitaker]

cc @mitsuhiko, this might actually be because of the introduction of the title concept. I think we just need to fix the zulip thing here (which means you will also have to change your webhooks @href), but I am not really sure.

I for one wasn't aware that raven infers a message from the exception, but I just looked at the code and indeed it does.

[mitsuhiko]

So the zulip thing might be that message was incorrectly set in Sentry. The message attribute in the event payload is supposed to relate to the logentry.formatted attribute. However it incorrectly as also set to an internal search message which was never supposed to be exposed.

I think the correct fix here would be for zulip to pick up title instead.

[mitsuhiko]

But to clarify what is supposed to happen:

• title is always set and is a summary of the event
• message is a legacy attribute that is an alias for logentry.formatted
• New SDKs should not emit message alongside exception.

[href]

Just to clarify, that should be event.title, right? I don't see a title attribute on the incoming webhook data (see my original description of the issue).

[mitsuhiko]

@MeredithAnya are we happing the title event payload to event.title in the webhook event payload?

[JeronimoColonSP]

Bump and do you have an answer for the last part of the OP's question: "Also, Is there some documentation about the webhook message format?"

[MeredithAnya]

@href @JeronimoColonSP our best 'documentation' right now for this would be where the code lives https://github.com/getsentry/sentry/blob/eed6157b477d9bd45b04ee69976c697a30280730/src/sentry/plugins/sentry_webhooks/plugin.py#L77

Sounds like event.title is what you need. An issue can have a title as well which i think uses the title from the latest event (@mitsuhiko maybe you can fact check me on that)