Select Topic Area

Bug

Body

Reproduction steps

1. Create a PAT with contents:write and access to a repository with a large number of active GitHub Actions workflows (50+, perhaps?)
2. Use that PAT to create a new branch in that repository. Make a POST request to /repos/{owner}/{repo}/git/refs

Expected behavior

POST request succeeds

Actual behavior

POST request intermittently fails with several responses:

• 500 (no body)
• 502
• 422

Workaround

Grant the workflow scope to the PAT

Notes

This issue took us several days to diagnose. We have a critical process that's responsible for creating branches in our primary repository that hosts dozens of GitHub Actions workflows, thousands of branches, and over ten years of commit history. This branch creation process started failing over the past two days with varying response codes: 201 (sometimes), 422, 502, and 500. None of the responses were indicative of the actual cause, and it only seemed to occur against our primary repository.

During the investigation, we noted that the PATs we generated to reproduce the error would receive a response from the API substantially faster than the token we use in production. We also noticed that our PATs did not seem to encounter the instability that the production token did. At first, we thought replacing the app's OAuth token with a PAT might resolve the issue, but it did not. This led us to begin investigating the possibility that the permissions granted to the token could impact the stability of our requests.

Once we granted the workflow permissions to the app's token, it began to receive responses from the API much more quickly, and we have not yet noticed further error responses.

We find this interesting, because we do not have any workflows with an on: create trigger.

Our interpretation of the issue is that GitHub must have some kind of conditional logic involved that makes the request take longer when the token does not have the workflow scope granted to it. We also believe that the number of workflow files in the repository impacts the likelihood of encountering these errors, possibly as a result of iterating through all workflows without the necessary permissions.

While the endpoint documentation states that either contents:write or contents:write and workflow scopes must be granted, it does not clearly describe the impact of a missing workflow scope.

Desired outcome

• Update the endpoint documentation to describe the impact of the workflow scope to include stability and performance considerations with respect to large, old repos with many GitHub Actions Workflows
• Address the underlying performance and stability bug that causes git ref creation requests to fail when workflow scope is not granted or necessary