View important Sentry error details in GitLab

added to epic &1625

changed the description

@ameliabauerly Here is a new issue for displaying more info/details for each error in the table of errors. We will determine what those pertinent details are via the interviews we have in the coming weeks! I wanted to get this created so that we have something to plan for 12.5

Cool, thanks! We had some initial ideas for this last year. Posting the initial sketches for reference. Pretty bare bones but wanted to at least capture what we had discussed previously.

@ameliabauerly thank you! I looked through them and I think this is an excellent place to pick back up. Are these Balsamiq sketches from the fast-boot?They look to be "visionary" and I am curious if we did any work to validate/invalidate any of the ideas? Thank you!

We put these sketches together before the Fast Boot. We used them mostly to determine the scope of the work we could complete during the Fast Boot, as far as I can remember. In seeing them, we decided to focus on the settings page and the list view only, so at that point the detailed error view was not explored further.

I don't think we did any work to validate/invalidate these ideas with customers, they were just first sketches. I think the idea was to build the initial integration and list view, get feedback, and see whether having a detail view within GitLab was in fact useful, or if users preferred just to go directly to Sentry for more details about the error. I don't think we've ever gotten feedback on that point, though. It does seem like this is something it would be good to further validate. Perhaps we can start by asking internal users of the Sentry integration the following:

Whether they expect to see more details about the error in GitLab or whether they prefer to get this information directly from Sentry?
If they want a detail view within GitLab, what information is it most useful to show?

I believe @joshlambert spoke on this point a bit during our call today. It seemed like he was suggesting having more of a card view in GitLab, rather re-building a full error detail page that would essentially be repeating information users could otherwise get in Sentry. So I guess that could be sort of a half-way approach here, as well, leaving us somewhere between a simple list and a full detail view.

In terms of validating our approach, another way forward might involve designing a simple detail view and a card view with a link to Sentry, and then see which option users would prefer.

@awhite-gl, wanted to check in: do you have recommendations for how best to proceed here?

@ameliabauerly When you say "card" view, what are you imagining?

I am imagining the table (as it is today) with the option to expand each line and expose more details...is that in line with your vision?

Thanks for checking in on this! So, when Josh originally said card view, I was thinking something like the Operations Dashboard, or perhaps something like the "Overview" tab in Sentry, which is more of a dashboard view of the errors.

I did some thinking about both of these ideas yesterday. An operations-dashboard-style card view feels like it would make it much harder to sort through errors than a plain list in a table. And, while an Overview dashboard does feel like it would be an interesting add to our Error Tracking offering, it isn't really solving the problem we're trying to solve in this issue. Our goal here, as I understand it: to give users more information about errors so they don't necessarily have to go straight to Sentry and to do this in a way that doesn't involve having to completely re-build the Sentry Error Detail View, which would be a pretty huge investment that may not be needed at this time.

Having the expandable/collapsible list rows is definitely an option for solving that particular problem. My hesitation with going that route is that we don't really do that on any of our other tables. We do have examples of richer table rows, though, and it seems like we might want to utilize one of the existing table frameworks here rather than designing a new paradigm. The Security Dashboard seems like the closest fit to our use case, as it allows for interaction to show more details, and also allows users to create issues, click for more information, add comments, etc.

I'll add a concept I worked on last night that experiments with the Security Dashboard template in new thread for discussion!

changed milestone to %12.5

added Category:Error Tracking devopsmonitor direction grouprespond labels

added [deprecated] Accepting merge requests label

I've put together a sketch for how the Sentry list view could work if we follow the Security Dashboard "template." This is still very much a rough draft but, wanted to at least post what I was working on so we can start discussing.

List view, default	List view, hover	Error detail in modal

Thoughts on these designs

I've included features in these designs that aren't necessarily part of the work for this specific issue, but that we are going to need longer-term if this list view is actually going to be usable. Primarily, this includes adding in a filter bar (with search, sort options), and adding in bulk action buttons (I'm thinking resolve and ignore as the options here). All of these details would need to be further defined and the design for them is still very much WIP but, also wanted to start sketching the larger vision for this page so we can see how this work fits into it.
Following what's done in the security dashboard, users can hover over any row and see a number of action buttons. For this specific issue, we could work on adding in the hover state and the "more information" button. The rest of the buttons could be added in separate issues.
With the detailed view, here presented in a modal: I took a quick stab at content that seemed useful here. We can add different content, or even more content. I suggested linking directly to "releases" as that's what Sentry does, but maybe we can link directly to specific commits instead?

Again, this is all a quick sketch. Love to hear your thoughts, @sarahwaldner, @nadia_sotnikova, @awhite-gl!

@ameliabauerly Thanks for the first iteration of designs. Here is my feedback!

Feedback:

I don't know if a modal is how we want to be showing additional details for an error (as you and I discussed). What about a drawer that expands and collapses? (I also don't know if drawer is the correct term here...)
The hover over i icon makes me think of a text pop-over that gives me a definition or instructions
I think we want the stack trace somewhere in this view BUT stack traces can come in many different shapes and sizes so viewing it in a table may not be ideal

Questions:

What does the orange X on each listed error do?

@ameliabauerly thanks for putting these together. A couple of questions:

Do we have defined interaction patterns in Gitlab UI or Pajamas for tables? (even if it isn't available yet?) We should follow the standard pattern for tables if it's documented, I'm assuming always showing the actions is the preferable pattern.
I agree that we should not be using modals for any alert details view, can we get some screens to show what alerts look like in Sentry? I'm not sure that using a code block is the best route or not, could that be confusing to a user?
Do we have any idea when the sliding panel component will be available?

@awhite-gl - responses to your questions:

Do we have defined interaction patterns in Gitlab UI or Pajamas for tables?

There is some documentation. Basically, it recommends having the buttons always visible and using a button group when there are multiple actions.

I agree that we should not be using modals for any alert details view, can we get some screens to show what alerts look like in Sentry?

In our call today, I shared the link to the Sentry dashboard. Let me know if that helps or if you need any additional views captured here!

Do we have any idea when the sliding panel component will be available?

They are working on the design currently, so I'm guessing in the next couple of milestones. Capturing a couple additional thoughts from our call on this issue:

The panel view, as currently designed, works over a card layout (as on the issue board). We haven't yet defined how that would work in context of a table/list page. On a majority of our list pages, clicking into a list item links users to a new page, where they will see more information. My proposal is to follow that approach here, since that appears to be the standard behavior.
We can definitely consider moving this layout to a card layout - or even to build out an overview page that utilizes a card layout. To me, these feel like more of a total re-design of what we have now. I'm not sure if we want to take that step at this point?

marked this issue as related to #33156 (closed)

mentioned in issue #33156 (closed)

Hi @ameliabauerly !

Not sure whether I can provide useful feedback considering my limited understanding of the problem, but here are some thoughts and questions to spark further ideas.

Context switching is a very important consideration here, users will be floating in and out of Sentry and we want that process to be as smooth as possible. Sentry displays error issues in a table, so it's good to keep the layout and interaction patterns as familiar to the user as possible.
At first glance, the main actions in relation to an error are Resolve, Ignore, and Create an Issue (or link to an existing issue). I think using the same hover action buttons as in the Security Dashboard doesn't map to the error actions as well. Will the orange cross button "Ignore" or "Resolve" an error? It's the same color as Resolve yet the metaphor of the cross is destructive (ignore or delete). Regarding issue creation, can we allow the user to find and map the error to an existing issue, in addition to creating a new issue?
Sentry provides a link to the file where the error occurred, and seems like we also do it for Security Vulnerabilities in CI/CD. Perhaps it would be important for error tracking?
Have you thought of the default states for the filter? Sentry filters by is:unresolved by default.
Would the modal be full-screen on small screen sizes?

This is awesome feedback, thanks @nadia_sotnikova! Quick responses:

I think using the same hover action buttons as in the Security Dashboard doesn't map to the error actions as well.

I agree, I was thinking the same. My first pass was to see if/how it mapped to the Security Dashboard. I was also thinking that, if we stick to this metaphor, perhaps all the icons should just be grey to avoid the color confusion?

Regarding issue creation, can we allow the user to find and map the error to an existing issue, in addition to creating a new issue?

At first pass, just to create a new issue. But I think that is an excellent idea and functionality we should add in down the line, definitely!

Sentry provides a link to the file where the error occurred, and seems like we also do it for Security Vulnerabilities in CI/CD. Perhaps it would be important for error tracking?

Agree, great suggestion!

Have you thought of the default states for the filter? Sentry filters by is:unresolved by default.

I haven't yet! But, I agree, "unresolved" seems like a good default option

Would the modal be full-screen on small screen sizes?

In talking to @sarahwaldner this morning, I'm wondering if the modal will be a good fit longer-term. If we are, for instance, thinking of putting a full stack trace into the error detail, that content probably won't fit very well in the modal. I'm almost wondering if we should instead follow the existing label workflow, where the action icons are always visible and clicking on one of the icons opens up a new page?

Sarah W is going to post some comments and then I'm planning on posting a second version based on both of your feedback. I will ping you as soon as that's ready!

@ameliabauerly @nadia_sotnikova I added my comments/questions to the discussion right above this one, here. So that we do not confuse comments across different discussions, let's stick to this one OR, @ameliabauerly , when you post a second iteration of designs start a new one and we can keep going there.

added Deliverable documentation release post item labels

@sarahwaldner and @nadia_sotnikova - Posting v2 in a separate thread for your review.

Since this detail view is one piece of a larger set of changes we'll want to make in the longer-term on this page, I've been considering the design for the detail page in context of these other changes, just so we make sure and leave space for additional improvements down the line.

I played around with a number of different visual treatments for the ignore, resolve and create issue in-line buttons. I've landed on a couple options that seemed worth sharing:

Roughly based on the security dashboard, where the icon buttons have color and don't appear in the row until the user hovers over the row

Default view	Icons with tooltips

Roughly based on the pipelines list, where the action icons are grey and always present

Default view	Icons with tooltips

Since both of you suggested that a modal might not be the best place to show the detail view (and I agree!), I explored other options for displaying the error detail view. I did explore a drawer view, as Sarah suggested. But, for me, the drawer view has the same problems as the modal: there's not a ton of space there. This is especially true given what we heard in our user feedback sessions. The first thing users check when they investigate errors is the stack trace. It doesn't seem like a great experience to view a stack trace in a sidebar For this reason, I've opted to follow what's done, for example, in the issues list, in the commits list, or in the pipelines list. In all of these cases, clicking on the row title opens up a new page where further details are shown. I've followed that pattern here, and based my designs for the error detail page on the commit detail page.

Obviously, for this first pass, we don't need bulk actions or space for an overview dashboard. Simplifying these longer-term designs down to a next iteration and focusing in on creating the detail page, then, would leave us with something like this:

Default list view	Error detail view

The work for this issue would include removing the 'external link' icon from each individual error title on the list page. Instead, clicking on the error title would now link to the error detail page. The link to view the full error details in Sentry would now appear on the error detail page, in the "error details" section.

For a first pass, I assumed the error detail page could include the error title, description, some basic error details, and a stack trace. I've suggested a number of error details to include (along with suggestions for what they could link to). But, we'd have to confirm all of these details with engineering, to figure out which of these options is possible.

A note on the stack trace: the stack trace in Sentry is a table with expanding/collapsing rows. Creating something like this seems like it would be a pretty heavy lift, especially since we don't have a UI pattern for expanding/collapsing table rows yet. I'm thinking that a first-step here might be to display the stack traces in code blocks, along the lines of what we do in our commits page, so we don't have to totally reinvent the wheel as a first pass. Right now, what I'm showing in my design is a screenshot of a code block on the pipelines page. But, we'd likely need some engineering exploration to see what's possible here.

Things I'd like feedback on:

Preference for how to display the action buttons? Do you prefer the security dashboard-style buttons (which are invisible until they are hovered on, and have multiple colors when they do), or the pipeline-style buttons (which are always present, and always grey)? I think I prefer the always present buttons, so the actions aren't hidden but, there are pros and cons to both approaches so I'd love to hear your thoughts!
Thoughts on my suggestions for the error detail page?

Would love any thoughts you have!

cc: @awhite-gl, @ClemMakesApps and @sengelhard for visibility

I prefer the present buttons because it's more visible and easier to know how to take action. I think what you proposed above with the error detail page is great. I think we should be able to leverage some of the components from the create team :)

@ameliabauerly

Preference for how to display the action buttons?

I also prefer the always present buttons so people know actions are possible

Thoughts on my suggestions for the error detail page?

I like it, but I am worried that it is taking us too far down the road of rebuilding errors that already exist in Sentry. Additionally, I agree that it is going to be hard to put Stack traces in issues. I have no idea if those can be embedded. Since we are not building errors as first class objects in GitLab, do we see any technical concerns with the errors details page, @ClemMakesApps @seth? Since we can populate it via API, I dont think we need to store error data. Please correct me if I am wrong.

Question: Is the stack trace necessary to determine if the error is critical? OR does someone go look at the stack trace AFTER they have determined an error is critical and needs to be fixed?

If the latter, we could hold off on putting stack traces in GitLab issues and just stick to including title, description, frequency, # of impacted users, and link to the stack trace...

I spotted #33417, and wanted to flag it here. I've asked the person who edited that issue to confirm but, I'm presuming this is a GitLab issue created from the Sentry UI. I note that it includes a small code block in the issue description. I'm not sure what, exactly, this small code block is - is it a small summary of the error or of the stack trace?

I ask as, perhaps we could include something like this in our detail view rather than the full stack trace?

@ameliabauerly Great find! Let me know what they say. Maybe we can pull them in on a review of designs after the next iteration?

I am not sure if that is the plain text stack trace - but let me know what they say. thank you!

@ameliabauerly I also prefer the buttons that are always there!

One thing I'm thinking about is whether there's a need to establish some type of hierarchy between those three buttons (Ignore, Resolve, and Create Issue). Not sure where you're at with the research on this, but it's something to talk to the users about.

For example, is Ignore a destructive action that would lead for the error to disappear, or can we view ignored errors by filtering the list? I'm asking because we don't want the user to accidentally delete an error that they meant to resolve. The buttons are very close to each other and have the same color. The destructive action needs to be de-emphasized.

What action will be the most common? Will most errors be resolved? May be a good idea to somehow emphasize the primary action.

I think that stack trace will be important but I don't think it should stop us from descoping it from a first iteration.

My concern with the detailed view is whether we are surfacing the right information. Current workflow I see we use at GitLab is:

There is a crisis, we need to figure out what is causing it
Check Sentry and Kibana to see if we can figure out more about the cause of the issue

I am concerned that in this type of workflow, one would choose to go to sentry directly since they can surface more information than our "summary" of the sentry error view. At some point, I do hope our error tracking can provide a more proactive workflow, but I just wanted to leave this note here as a consideration :)

I think that stack trace will be important but I don't think it should stop us from descoping it from a first iteration.

I agree with this statement. Stack traces are important in determining where the error is happening. I think it's something we want ultimately, but it's fine to descope it for the first iteration. If we find out it's relatively easy to get a stack trace from Sentry and we can render it very plainly, that would be a great follow-up issue that we could do next.

Thank you all for this great feedback. Will try to synthesize these comments into a V3

I've updated the designs for this issue based on latest discussions. 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

Basically, 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.

Also, I've uploaded all of these designs to Sketch cloud. The designs are grouped as MVC, medium term options and longer term options. The medium and long term options are more for a record of the things we discussed above.

cc: @nadia_sotnikova, @awhite-gl, @sarahwaldner - in case you have any comments/thoughts/suggestions on the MVC proposal

@ameliabauerly The MVC looks good. I want to make sure we are on the same page for the scope of this issue. For 12.5, we will be improving the list of Sentry errors in GitLab and adding a search bar. This issue is for improving the list of Sentry Errors in GitLab. When I compare the design you listed above to what it looks like today, I do not see a ton of difference. I could be missing things. Could you tell me what changes we are making to the table? Thanks!

What it looks like today:

@ameliabauerly Additionally, we need to adjust the description of this issue so that it describes the scope of work to be done, which is improve the List view of Sentry Errors. After reviewing the discussions above, I don't believe that we are making any significant changes to the List view of Sentry errors in GitLab. I am curious if we should combine this issue with #33883 (closed).

@sarahwaldner - This issue was originally focused on building a simple detail view, so that's what the designs proposed thus far focused on. From the title and description changes, it looks like that's no longer the focus for this issue anymore, and that we are instead focusing on improving the list view. Is that right? Have you created a different issue to focus on the detail view? That still seems like an important next step.

If this issue is now primarily focused on improving the list view: currently, the list view displays the error title and description (in one line, as that's how the information is returned from the API). It also displays the "culprit" of the error, the time the error was recorded, how many events were recorded, and a sense of the impact. Originally, the error title also linked to the Sentry error.

The only thing I was proposing changing on the list view in the designs posted here was replacing the link to Sentry in the error title with a link to the error detail page. The goal here was to surface more information about the error directly within GitLab (including, ultimately, the stack trace) so that people don't have to go directly to Sentry but can instead work within GitLab as they investigate errors.

The only other improvements I was proposing to the error list page in the short-term were to improve the search/filtering options, and to add the ability to create an issue about an error directly from GitLab (which could happen either from the list row or from the error detail page, though I believe we were landing on creating the issue from the error detail page in last week's meeting). But I believe these are also separate issues now?

cc: @nadia_sotnikova

@ameliabauerly As per our Zoom call, The scope of this issue is to build the Detail view of an error and link it to the title of the error in the list. The scope DOES NOT include making significant changes to the list of errors. I apologize for the confusion that I caused! I updated the title, problem to be solved, and proposal section of this issue to reflect this.

Perfect, thanks Sarah!

@sarahwaldner - updated the designs in the issue description after our call and added the workflow::ready for development label. I think everything is ready to go for now but, if you think of anything else here, just let me know!

@ameliabauerly Minor copy change, the button on the error detail view should say Create Issue not New Issue, since you're creating a new issue from this error.

@awhite-gl - sure, was going back and forth about that ("create issue" makes more sense in this context but I see "new issue" more often). Have updated the design in the issue description!

Also, a quick question - Kenny asked how the user gets back to the list view page. I was originally planning on following the pattern we use on issue, commit and MR "detail" pages, which is, people can utilize the browser back button or the breadcrumbs to return to the list view. On those other pages, there is no explicit button that allows users to return to the list view. Do we want to introduce a button for users to click to return to the list view for errors? If so, where should it live?

I commonly see this feature represented in other products as a back arrow somewhere in the top left part of the page (next to the page title, for instance). But, we don't have that pattern anywhere in GitLab. I also feel hesitant to add a "back to list" button in that top bar next to "create issue" since we are holding that space for the ignore/resolve buttons we are planning to add in later iterations, and I don't want there to be that many buttons up there. The only other place I can think of adding it would be at the bottom of the content, but that isn't ideal either, as it would likely be pushed pretty far down the page when the stack trace functionality is fully built out:

Do you think we should prioritize adding a "return to list" button as part of this first batch of work or should we save this piece for a follow-up?

cc: @nadia_sotnikova

@ameliabauerly I think the Bread crumbs across the top are sufficient as this is a common pattern throughout the app, as you said. Perhaps we change the word Errors to Errors List to be more explicit. Thoughts?

I think that's a great suggestion. I've updated the design in the description!

I agree with Sarah's suggestion.

mentioned in issue #26930 (closed)

changed the description

assigned to @ameliabauerly

added UX label

added designideation label

changed the description

marked this issue as related to #26026 (closed)

mentioned in issue #26026 (closed)

mentioned in issue gitlab-org/monitor/general#36 (closed)

removed [deprecated] Accepting merge requests label

changed epic to &2029

removed Deliverable label

changed the description

changed title from Detailed view for Sentry Errors in GitLab to List view for Sentry Errors in GitLab

changed title from List view for Sentry Errors in GitLab to Detail view of Sentry error in GitLab

changed the description

marked this issue as related to gitlab-com/Product#480 (closed)

@kencjohnston Please review this feature MVC for the ~"group::health" for 12.5! Apologies for the late notice.

mentioned in issue #33838 (closed)

changed the description

added workflowready for development label

The goal of this MVC is to provide the user with enough pertinent information so that they can make a decision about what to do with the error - ignore it? triage it for later? fix it right away?

@sarahwaldner - This is great context AND scoping. Nice work.

@sarahwaldner @ameliabauerly - MVC looks good, you've provided a good deal of options for descoping. I do wonder if the UX of starting with a dedicated page view is more than minimal. Can the same experience be accomplished in a pop-out modal for a first iteration? As it stands now, I'm not certain how if I'd clicked into a specific Error I would think to quickly get back to the list. Perhaps it is the breadcrumb, or my browser back button, but a model would make that much more intuitive.

Thanks, Kenny! We did discuss a modal but, since we are going to want a stack trace in the next iteration, it seemed to make more sense to build the framework that will hold the stack trace sooner rather than later. Otherwise, we would have to build the modal only to deprecate it almost immediately.

Your point about returning to the list page is great, and I think we can make that more clear than we are currently (right now, we're just relying on the breadcrumbs). Will include this change in my next batch of updates!

I believe we have a well established interaction pattern for going into a new view to consume further details (MR's, Issues, Pipelines, etc...), also a modal won't allow us to scale the UI to address further feature improvements, take advantage of the code UI to view the errors on small screen sizes efficiently.

It seems to me the most difficult part of this feature is getting the data out of Sentry vs. displaying in a modal vs. new view.

changed the description

@sengelhard I'm going to add frontend and backend since this is workflowready for development.

We should mark this Deliverable since it's at the top of the list

added backend frontend labels

changed the description

assigned to @ohoral

added Deliverable label

mentioned in issue #34258 (closed)

added workflowin dev label and removed workflowready for development label

Please provide a quick summary of the current status (one sentence)

I've just started working on it

When do you predict this feature to be ready for maintainer review

I plan it for the first review next week. But it also depends whether BE is ready

Are there any opportunities to further break the issue or merge request into smaller pieces (if applicable)?

I do not think so

/cc @ClemMakesApps

@sengelhard do we have someone assigned from the backend for this?

@ClemMakesApps - No, we don't. I'll go ahead and assign @seanarnold. @seanarnold let me know if you'd like to discuss this.

View important Sentry error details in GitLab

Problem to solve

Intended users

Further details

Proposal

Design

Permissions and Security

Documentation

Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Links / references

Designs

Child items ...

Activity

View important Sentry error details in GitLab

Problem to solve

Intended users

Further details

Proposal

Design

Permissions and Security

Documentation

Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Links / references

Relates to

Activity