<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=505101) </details> <!--IssueSummary end--> From https://gitlab.com/gitlab-org/gitlab/-/merge_requests/172179: I think we should have a follow-up issue here to refactor to handle errors better. We can add an `errors` field that actually has the errors. One challenge here is that the `QuickActionsService` doesn't really distinguish between successful and unsuccessful execution of commands. It simply returns the execution messages: https://gitlab.com/gitlab-org/gitlab/-/blob/3d20fd45ec2b24ff02a06eea0ef1558f522a211d/app/services/quick_actions/interpret_service.rb#L51 The only time we definitively know if an error occurred is if the execution message is blank and there were commands in the note. In that case, `error` will be set to `true`. For example, if we have something like: ``` /spend 1d /spend bogus ``` The first `/spend` will succeed, but the second will not due to the invalid `bogus` value. As a result, the execution message for the two messages are: 1. `Added 1d spent time` 2. null In https://gitlab.com/gitlab-org/gitlab/-/blob/3d20fd45ec2b24ff02a06eea0ef1558f522a211d/app/services/quick_actions/interpret_service.rb#L176, the message returned is joined with a space. As a result, `message` is simply the first message, and no error is signaled. In this case, this execution is considered a successful quick action, even if the second one failed. I think that is fine for now. However, I think what we really want is to: 1. Determine whether an action failed, regardless of the execution message returned. 2. Have the GraphQL API return successful commands in `messages` and unsuccessful messages in `errors`.