sentry-java

sentry-java copied to clipboard

Description

This is split off of https://github.com/getsentry/sentry/issues/84502, to specifically talk about the DiagnosticCoroutineContextException errors mentioned there and the way they're affecting grouping and titling of issues.

The main problems reported there:

• The DiagnosticCoroutineContextException errors have no stacktrace and no message, and so we're ending up grouping on error type only, which is putting chains with different ~inner~ outer errors into the same group because their ~outer~ inner errors are DiagnosticCoroutineContextException in both cases. (This was the original inspiration for the issue.)
• DiagnosticCoroutineContextException is being used as the title for different groups, making them hard to differentiate in the issue stream. (See comment here.)

IIRC, this has come up before, and we've gone back and forth (on GH and in Slack) about what should be the main exception and what should be suppressed, and whether the solution lies in the SDK or on the server, and AFAIK we didn't really come to a firm conclusion and make a plan. Since it's now come up again, I figured maybe we could centralize the conversation in one spot and get to a decision on how we want to handle things. I'll add my understanding of where things stand as a comment below.

Just to have an example to work with, let's consider the following event data:

{
  "exception": {
    "values": [
      {
        "type": "IllegalArgumentException",
        "value": "View=DecorView[Main] not attached to window manager",
        "module": "java.lang",
        "stacktrace": {...},
        "thread_id": 2,
        "mechanism": {
          "type": "UncaughtExceptionHandler",
          "handled": false,
          "is_exception_group": true,
          "exception_id": 0
        }
      },
      {
        "type": "DiagnosticCoroutineContextException",
        "module": "kotlinx.coroutines.internal",
        "thread_id": 2,
        "mechanism": {
          "type": "chained",
          "exception_id": 1,
          "parent_id": 0
        }
      }
    ]
  },
  "main_exception_id": 1,
  "title": "DiagnosticCoroutineContextException"
}

On the server side, what happens is this:

• We see that the IllegalArgumentException is marked as an exception group, with the DiagnosticCoroutineContextException as its only child , so we a) ignore IllegalArgumentException for the purposes of grouping, b) therefore group only on the DiagnosticCoroutineContextException, and within that only group on error type, because there's no stacktrace and no error message, and c) set main_exception_id to point to the DiagnosticCoroutineContextException.
• When it comes to titling the event, we see main_exception_id = 1 and therefore use DiagnosticCoroutineContextException as the title (again only using the error type because there's no message).

Random thoughts/questions:

• A user in the original issue solved this by simply deleting the DiagnosticCoroutineContextException in their beforeSend. I presume it has some value, though, right? So that's not a great solution in general?
• From what I recall, the point of marking it as an exception group is to get the UI to behave the way we want, correct?
• Things would be different if there were multiple child exceptions of different types. Does that ever happen?
• One way to handle this would just be to special-case it on the server. Are there other examples of things like this, where it's "real error marked as a group and as the parent of a generic, low-info error?" And is that generic, low-info error always a DiagnosticCoroutineContextException?