Replay: Errors count on replay detail include `captureMessage` with any level

[bruno-garcia]

Problem Statement

Customer feedback:

Not really a question, but with the understanding we represent Messages as Issues, still feels a bit strange to have captureMessage reflected as an Error in the Replay timeline (and traces). Wish we had different iconography for these.

An SDK call to Sentry.captureMessage results in a event with type: default. That's because no type is sent from the SDK, and Sentry changes sets the type: error if it finds a stack trace. Which isn't included in a captureMessage unless the SDK option attackStacktrace: true.

Additionally a user can override the level:

Sentry.captureMessage("this was a serious problem", "fatal");

Today, the message above wouldn't be counted as an error in the Replay UI ^

Solution Brainstorm

Make sure the SDK considers event.level in addition to having a stack trace in order to tag events with replay_id. In the Replay detail UI, consider event.type: default in addition to event.type: error for as long as level > error. This would leave warning and lower out of it but we can agree those are not errors.

Related to: https://github.com/getsentry/replay-backend/issues/247

[cmanallen]

Back-end error counts only consider error and fatal log levels.

[cmanallen]

@bruno-garcia Can this be closed?

[billyvg]

This still happens, see this replay

Today, the message above wouldn't be counted as an error in the Replay UI ^

This is not accurate, all captureMessage() events are counted as errors in the UI.

From the SDK side, when in buffer mode, we only look at the existence of event.exception (i.e. it has a stacktrace) and event.type existing, meaning that captureMessage (by default) should never trigger onError sampling.

Open questions:

• Do we want the SDK behavior to match UI behavior? (capture replays on error + fatal message levels)
• What type of events do we want to include/exclude for the Errors tab/count on the UI?