Exception 'You do not have permission to view this repository' on scheduled workflow run

[spier]

I have a workflow that runs on a monthly schedule to generate PR and Issue metrics.

When it ran on the schedule yesterday, it failed with this error:

You do not have permission to view this repository; Check you API Token.

However when re-running the workflow again, it succeeded.

Not sure if this was a blips in the matrix or what happened here :)

For context:

The workflow file is in the same repo for which metrics are generated.
Therefore I believe I can use the default secrets.GITHUB_TOKEN token that is automatically generated for each workflow run.
Also the fact that the 2nd run succeeded seems to indicate that this is not a general permission issue.

[zkoppert]

Oh wow! That is surprising. My guess is that this is a glitch but will keep the issue open for now in case we get any other reports of the same thing.

[zkoppert]

Closing as we've not seen this again. Please re-open if spotted again.

[EricStG]

We have the same issue. In a schedule, we get:

Starting issue-metrics search...
Searching for issues...
You do not have permission to view this repository; Check you API Token.

But run it manually and every thing is fine

[zkoppert]

@EricStG can you confirm that the PAT you are using manually and in the action are the same?

Is your workflow referring to the default token or one in your repository secrets?

[EricStG]

@zkoppert We're using the default token, it's the same regardless on how we trigger the job

[zkoppert]

@EricStG I'd recommend setting up a Personal Access Token or App private key and ID. The default token in my understanding is unable to be granted cross repo permissions. Here are some docs with your options for setting those up:

• See Step 5 listed here: https://github.com/github/issue-metrics?tab=readme-ov-file#use-as-a-github-action
• GitHub App authentication method: https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/about-authentication-with-a-github-app
• GitHub Personal Access Token Method: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic

[EricStG]

@zkoppert We can use a PAT, but just so you know, the workflow is in the same repository that is being queried

[zkoppert]

Interesting. Maybe I'm pulling on the wrong thread. Do you grant permissions in your workflow file?

[EricStG]

Yes, we grant issues: write and pull-requests: read

Here's the workflow

name: Monthly issue metrics
on:
  workflow_dispatch:
  schedule:
    - cron: "3 2 1 * *"

permissions:
  issues: write
  pull-requests: read

jobs:
  build:
    name: issue metrics
    runs-on: ubuntu-latest

    steps:
      - name: Get dates for last month
        shell: bash
        run: |
          # Calculate the first day of the previous month
          first_day=$(date -d "last month" +%Y-%m-01)

          # Calculate the last day of the previous month
          last_day=$(date -d "$first_day +1 month -1 day" +%Y-%m-%d)

          #Set an environment variable with the date range
          echo "last_month=$first_day..$last_day" >> "$GITHUB_ENV"

      - name: Run issue-metrics tool
        uses: github/issue-metrics@v2
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SEARCH_QUERY: "repo:${{ github.repository }} is:pr is:merged closed:${{ env.last_month }} -author:app/renovate"
          HIDE_LABEL_METRICS: true
          HIDE_TIME_TO_ANSWER: true

[zkoppert]

Can you print the value of github.repository and ensure the format and repo its pointing to are correct? org/reponame ie. github-linguist/linguist

[EricStG]

they are both the same, repo:owner/repo
from the logs, the arguments passed to the action are identical in every way

[zkoppert]

Interesting. @jmeridth Any thoughts on this one? Something I'm missing?

[jmeridth]

@zkoppert like you, this sounds like a token issue to me but it working on second attempt is the weird issue. I'm going to test out some stuff to see if I can recreate the problem. Thank you @spier @EricStG for reporting this. We are looking into it.

[EricStG]

@jmeridth just to make sure:

• The schedule workflow never works
• Running the same workflow manually always works
• Retrying the failed scheduled workflow also works 🤷‍♂️

[lawang24]

can confirm had the same issue as above

[rolgalan]

I have also API issues similar to what is described here. My problem is not related to scheduled workflow, but executing on PR (I just want to generate the few past months before enabling the scheduling monthly).

Even if it does not happen in scheduled runs, my* workflow sometimes work and sometimes not*. It successfully completed a few times, but some other cases I am getting the following error: You do not have permission to view this repository 'glovo-customer-android'; Check your API Token.

This happens on the middle of the Searching for issues... stage, after printing several PR titles in the logs. Using exactly the same token and config it succeeded a few times. So the token definitively has the right permissions. I am using GH_TOKEN: ${{ github.token }} and trying to run it for the same repo (which around 300 PRs merged each month).

I waited a couple of hours since the last failure and the rerun succeeded. This looks to me like the primary rate limit is exceeded. Maybe the error message can be improved, and instead of this generic authorization error, the action returns the quota failure? It would help clarifying the reason of the failure to the user :)

[lawang24]

This issue seems to mirror symptoms of former issue #189 and thus might also be solved by feature request #217

One potential explanation for the mysterious behavior of failing on scheduled runs but succeeding on subsequent manual reruns could be other GHAs also hitting the search API at the same time? If a repo wants to track other metrics too and has several different Github Actions using this API running at at the same schedule (ex: first hour of month), they could be stack up and cause rate limit of API. However, by the time the repo administrator sees this failure and manually reruns it, the rate limit has already expired.

Unsure how to replicate this easily or how to fix it, but with some suggestions would be open to giving it a go

[zkoppert]

Yes, whether directly related to the cause or not, fixing rate limiting will at least rule out a potential cause. That seems like the best first place to tackle here.

[spier]

Let me just cheerlead a bit from the sidelines 👏

I am super happy that my initial bug report has taken on this life of its own and other cases of seemingly related issues were added. Also the responsiveness of the maintainers has been amazing. Thank you all for chiming in and exploring how this could be fixed/improved.

Lastly, the point by @lawang24 about multiple GHAs that run in parallel exceeding the GHA Search API rate limits does seem like a possible explanation indeed.

Again, thank you all for making open source awesome ❤️