`UnhandledPromiseRejectionWarning: HttpError: Label does not exist` on issues where not all labels are to be applied

[myakura]

I'm trying out this action; it works but I get UnhandledPromiseRejectionWarning(s) while the action is running:

Adding labels bug to issue #11
Removing label test from issue #11
(node:1471) UnhandledPromiseRejectionWarning: HttpError: Label does not exist
at /home/runner/work/_actions/github/issue-labeler/v2.4.1/node_modules/@octokit/request/dist-node/index.js:76:23
at processTicksAndRejections (internal/process/task_queues.js:93:5)
(node:1471) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:1471) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

It looks like it happens when not all labels are to be applied (i.e. most cases). Suppose I have the following label-matching definitions:

test:
  - '(test)'
bug:
  - '(bug)'

When an issue is filed with a body that contains both "test" and "bug", I don't see any warning. However, when the issue only contains either "test" or "bug", I see a warning. If the body contains neither, I see two warnings.

[myakura]

It may be caused by calling removeLabel() inside a forEach() loop.

issue-labeler/src/main.ts

Lines 79 to 82 in f40302d

	removeLabelItems.forEach(function (label, index) {
	console.log(`Removing label ${label} from issue #${issue_number}`)
	removeLabel(client, issue_number, label)
	});

The removeLabel() is an async function so the call will never be catched.

[lyndseypadget]

I use issue-labeler as the first of several steps in a GitHub action. If none of the conditions are met (meaning, the body contains none of the necessary keywords I'm looking for), then it throws this error. But because it doesn't fail the step, the following steps run anyway.

My scenario is like this:

name: "Issue Labeler"
on:
  issues:
    types: [opened]

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
    - name: If issue contains keywords, label it
      uses: github/issue-labeler@v2.5
      with:
        ...
    - name: If previous step succeeded, do the next thing
      if: ${{ success() }}
      uses: ...
      with:
        ...
    - name: If previous step succeeded, do the final thing
      if: ${{ success() }}
      uses: ...
      with:
        ...

I would expect it to fail the step. However, I can also see when it might be preferable to ignore the case where no keywords are found. This seems like a need for a configuration, where it fails the step by default (by handling the error appropriately) but the action author could override that behavior (still catch the error but suppress it with a nice message in the logs).