Errors are noisy and plentiful which makes triage processes time-consuming because it is difficult to sort through the cruft to find the critical ones. By providing the ability to resolve an error in the GitLab UI, we give users another tool to clear out errors that have been fixed, allowing them to easily focus on the one's that require fixing.
Add the option to resolve Sentry errors in GitLab. It should be available on the detail page in this iteration. Resolving an error should automatically close an associated issue.
Design
For the error detail page, we can add in a new button for Resolve, which will join the existing New issue and Ignore buttons.
Resolve error on detail view
When the resolve button is clicked, the user will be returned to the list view, where the error in question will no longer appear.
If an issue has been associated with the error, that issue will automatically be closed. We should consider displaying an informational alert letting users know that the "The error has been resolved. The issue linked to that error has also been closed." This message will likely appear on the list view, since users will be directed there as soon as the "resolve" button has been clicked.
When the issue is closed by the resolve button, we should have the system note mention that the issue was closed by the error resolution. The note should be worded: 'resolved the corresponding error and closed the issue'. It is also okay to break this into a separate tiny iteration but we should try to do our best to prioritize this for %12.7 (Context)
Permissions and Security
Documentation
Testing
What does success look like, and how can we measure that?
Sure, have added these details to the issue description!
Wanted to also link to the discussion on &2324 (comment 258921125) in this issue, since there is ongoing discussion there about alerts and whether or not to display system notes on issues closed as a result of clicking the resolve button.
@tristan.read is already OOO, @lauraMon @ohoral can y'all help out with this issue to make sure we can ship it? I'm not sure what progress has been made so far but this is one of the higher priorities and I'd like us to make sure we make it in. Thanks!
I've figured out that it happens per specific project. I've setup test project and it works fine but with ops-section-demo I still get {message: "Sentry response status code: 415"} (400 error from BE). In Sentry UI user whose API key I use to connect to Sentry does have enough privileges to change error status. Could you think about other reasons why this happens?
Also when error status is updated and redirect happens on successful response from BE, error list is not updated. It takes some time and couple of refreshes before error with ignored/resolved status goes away (FE cache disabled). In Sentry the status is updated immediately.
again about closing related GitLab issue on error resolve - are we doing it in scope of different issue/MR?
Hmm thats interesting. Which Sentry instance it that hosted on? I'd love to try it out.
That sounds like the reactive cache is kicking in. I might need to invalidate the cache when we update an object.. I'll have a look. That will be in another MR.
@ameliabauerly could you help here - do we want to add loading icon to ignore/resolve buttons while waiting for BE response? Cause we need to make sure that updated error list is being requested.
Sidenote to this: What do we think about staying on the error page after clicking these buttons?
When testing yesterday I found it odd that I'd be redirected to the list page.
For comparison, Sentry keeps you on the error page when clicking their buttons.
The original thinking here: if the user is resolving or ignoring the error, they wouldn't necessarily still need to look at the detail view once that error has been ignored or resolved, and that they would want to move on to looking at the next error on the list. That was the original idea behind returning them to the list view after the error has been ignored or resolved, that it would save them the extra step of having to navigate manually back to the list view to look at the next error in the list.
Maybe we can do a quick straw poll: @ohoral, @tristan.read, @syasonik, @nadia_sotnikova - if you resolve or ignore an error from the detail page, would you expect to stay on the detail page once the error is ignored or resolved, or would you expect to be returned to the error list view?
@ameliabauerly I'm working on the list view for this so I decided to chime in.
If I ignore/resolve an error from the details page, I'd expect to go back to the list view, since I don't care about the error anymore. If anything, I'd say maybe redirect to list when you ignore an error, keep on page when an error is resolved. But maybe it's confusing to have it like this?
I think I'd generally expect to stay on the detail view, personally. I'd potentially want to comment on a linked issue, close that issue, etc. I don't generally ignore/resolve as a last step.
I also agree that I'd rather stay on details page. In Sentry user can unresolve/unignore issue back. we'll have to add some visual indication of the status update (maybe the way it is done in Sentry - Resolve btn changed to Unresolve) in case it is decided to stay on details page.
@ameliabauerly thank you, I'll add the loading indicator.
Thanks everyone! It sounds like more of you would prefer to stay on the detail view (rather than being automatically sent back to the list view) after the error is marked as resolved. If we're staying on the detail view, it sounds like the button should change from "Resolve" to "Unresolve" so that the user can undo the resolve action later if necessary.
So, the resolve button will have three states:
Resolve --> Loading State --> Unresolve
@ohoral - how does that sound for you? If that plan makes sense, I will update the description accordingly.
General question for the group - I assume we will want this behavior to also apply to the "ignore" button as well?
I also think it's better to stay on the detail view. For example, when we close an issue, we're still in that issue, after it becomes closed. I find the "Ignore" action somewhat related. This pattern also gives more control to the user, which is usually preferred. @ameliabauerly
@ameliabauerly sorry, I missed somehow your comment. So I'd say it will be done in a follow up MR. which might not be merged in this milestone. will that work?
@ameliabauerly no, the code on FE side is common for both actions. So I'll do it in a single MR. I'll start today. also, shall I create a follow-up issue as I do not think this improvement can be pulled through the review by the end of milestone. We can add it to 12.8 What do you think?
the code on FE side is common for both actions. So I'll do it in a single MR.
Great!
shall I create a follow-up issue as I do not think this improvement can be pulled through the review by the end of milestone. We can add it to 12.8
I created a follow-up issue (#196881 (closed)) so that this new work doesn't impact the completion of this issue. @sarahwaldner - do you think it's okay to schedule this for 12.8 as @ohoral suggests?
Apologies, missed this one on Friday. Wondering if there’s a way to shorten this at all. Perhaps we could just say: Issue was closed as corresponding error was resolved. WDYT, @seanarnold?
@ameliabauerly the format is <user> <message> so that's why the translations start with a verb.
Perhaps it could be closed this issue as the corresponding error was resolved?
At the moment I"m using the user who pressed the 'resolve' button in the System message, so it would be @seanarnold closed this issue as the corresponding error was resolved.. Is that ok?
Sarah Waldnerchanged title from [2A] Resolve Sentry error from error tracking detail page to [2A] Resolve Sentry error in GitLab from error tracking detail page
changed title from [2A] Resolve Sentry error from error tracking detail page to [2A] Resolve Sentry error in GitLab from error tracking detail page
@sarahwaldner chances are high that in this milestone this issue will be delivered only partially - Resolve button on details page will update issue status and redirect to the list (BE& FE are merged already).
3rd (FE) - notification about closing related GitLab issue (In case 2 previous MRs are merged today) MR will be created tomorrow (the last day of milstone & I'm not sure it will get that fast through the review)
@ohoral
Thank you very much for the detailed update. I am happy with the partial delivery of this issue. Do we want to create new issues for the additional pieces and complete them separately in %12.8 ? I am talking about: