View important Sentry error details in GitLab
Problem to solve
Context switching slows everyone down. The unique UIs and interaction patterns of different tools make daily triaging tasks cumbersome. To overcome these challenges, we are adding to our integration with Sentry to provide a detailed overview for errors within GitLab. This allows you to review pertinent aspects of the error such as first/last seen, number of events, number of impacted users, and the stack trace in Gitlab without needing to switch to Sentry. You will be fixing the errors in code via GitLab, so as much review and work as we can keep in GitLab's interface, the more seamless we can make resolution. The goal of this MVC is to provide you with enough information so that you can make a decision about what to do with the error - ignore it? triage it for later? fix it right away?
We will avoid completely rebuilding errors in GitLab as this has already been done in Sentry and focus on simplifying the triage/resolution process.
Intended users
- Delaney (Development Team Lead)
- Sasha (Software Developer)
- Devon (DevOps Engineer)
- Sidney (Systems Administrator)
Further details
This work supports the Error Tracking Vision.
Proposal
There will be 2 ways to view an error:
- List view - Errors appear in a list and show only top-level details
- Detail view - This access by clicking on the title of an error in the list. It opens in a new tab and displays details of the Error.
Design is detailed in the following section.
Design
In terms of the work required for this specific issue, we are looking at the following:
| Remove external link from error title | Clicking error title opens new error detail page |
|---|---|
 |
 |
We're suggesting that clicking the error title from the list will now open up an error detail page. At a minimum, this detail page will include:
- A link to the Sentry error (which will open in a new tab if clicked)
- Error title and description
In addition, we can explore if any of the following pieces of information can be added:
- Information about when the error first occurred and last occurred
- A link to the file where the error occurred
- Links to "suspect commits" associated with the error
It's likely that the stack trace will be out of scope for this iteration but, added in a simple code block section as a basic formatting option should such information be easily available. The "new issue" button on the error detail page is also out-of-scope for this issue. It will be added as part of #33847 (closed)
Permissions and Security
Documentation
Documentation required, most likely here. I recommend creating a new section for the Error Detail page view that includes a small sub-section on Suspect commits from Sentry and links to their documentation on it.