Previously, a new utility to handle API errors has been introduced in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112193+ to be able to parse the error objects and extract the eventual user-facing errors to output to the user. As the next step, the utility has been refactored in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115061+ but with that, it introduced an unexpected side-effect of the utility with constructing the user-facing error using the same pattern already on the frontend. This should be considered an antipattern and this issue is aimed at finding a better solution. ### Possible solution Figure out what are the odds of an error object, returned from [the apollo mutation](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/vue_shared/security_configuration/components/manage_via_mr.vue#L49-L51) not having both `errors`, and `successPath`. If such scenario is impossible, the `if (!successPath)` branch of the code can be remove because it won't ever be executed. In this case, we still have to be able to provide a meaningful error message to the users, incl. the scenario where `successPath` is not available. This should be achieved by sending the correct user-facing error as part of the error object from the mutation.