[BUG] HttpError: Resource not accessible by integration - but it's working at a 2nd call

I was using the labeler quite a while now, so I can have nice labels for my mono-repo. But since a few weeks I get always(~99%) the same errors (see below), when Dependabot is creating PRs with dependency updates.

If I rerun the check, everything works as expected. Anyone else having this issue?

triage
HttpError: Resource not accessible by integration

triage
Resource not accessible by integration

My .github/workflows/labeler.yml looks like this:

name: "Pull Request Labeler"
on:
  pull_request:
    branches: [ main ]

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@main
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"
          sync-labels: true

my .github/labeler.yml looks like this:

project1-frontend:
  - services/project1-frontend/**/*

project1-backend:
  - services/project1-backend/**/*
  
project2-frontend:
  - services/project2-frontend/**/*

project2-backend:
  - services/project2-backend/**/*

[dannysauer]

I’ve also been seeing this a lot recently, only with this action (always from Dependabot, too).

It’d be nice if this would log something a bit more helpful in debugging what exactly it is that is not accessible. 😃

[jsoref]

So, I’d argue that this action should recognize when it’s in this state and explain itself.

Basically an action can know which event it’s running under (here: pull_request), and it can know which permissions it has/doesn’t have (here: it doesn’t have pull-requests: write), and it could spit out:

:warning: actions/labeler is running under `on: pull_request` without `permissions: pull-requests: write` and thus can't perform its work. To fix this, someone with write access to the repository will have to update the workflow to apply these changes. Refer to https://github.com/actions/labeler/blob/6a315d4ea58951035b498eef56668feaba24489f/README.md#create-workflow for more information on the recommended content for the workflow which should be helpful in fixing this workflow.

(Whether it hardcodes 6a315d4ea58951035b498eef56668feaba24489f, or uses git rev-parse HEAD / an equivalent environment variable is an implementation detail.)