[go: up one dir, main page]

Skip to content

Distinguish between successful and error messages in quick actions

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

From !172179 (merged):

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.
Edited by 🤖 GitLab Bot 🤖