Regular failures when trying to fetch PR's

[YorickH]

For the past week, we have been seeing a very non-descriptive error popup when trying to generate a changelog. We get an Error: Server Error at the point it's trying to execute a getBetweenDates API call.

🚀 Load pull requests
  ℹ️ Comparing org/repo - 'env-date-time-sha...env-date-time-sha2'
  ℹ️ Found 2 commits from the GitHub API for org/repo
  ℹ️ Fetching PRs between dates 2024-04-10T14:06.000Z to 2024-04-10T14:41:53.000Z for org/repo
  ℹ️ Retrieved 2 release commits for org/repo
  Error: Server Error

(obscured some details) The action is set up as follows:

      - name: Generate Changelog
        id: generate_changelog
        uses: mikepenz/release-changelog-builder-action@v4.2.0
        with:
          configuration: workflows/.github/generate-changelog-configuration.json
          token: ${{ steps.get_workflow_token.outputs.token }}
          fromTag: ${{ env.PREVIOUS_RELEASE_TAG }}
          toTag: ${{ env.RELEASE_TAG }}

I am not sure where to look for this one, Has anyone seen this happening? Is this possible that the maxPullRequests setting is needed here? How can we get more info besides this non-descriptive error? Often a re-run fixes the issue. We use an application token for authentication but would expect a different error in case auth would be the issue.

Sorry if I'm at the wrong location but had to start somewhere, why not with people having Github API experience?

[mikepenz]

Thank you for the ticket @YorickH Based on the logs it would appear that the most likely place is from Octokit pulling the diff: https://github.com/mikepenz/release-changelog-builder-action/blob/release/4.x/src/repositories/GithubRepository.ts#L99

Given we would have a log line after it gets the diff: https://github.com/mikepenz/release-changelog-builder-action/blob/94250de0148ccfb426e53db5dc1ab62e03e49cf7/src/pr-collector/pullRequests.ts#L152

Which then propagates the error up to here:

• https://github.com/mikepenz/release-changelog-builder-action/blob/94250de0148ccfb426e53db5dc1ab62e03e49cf7/src/main.ts#L113

Unfortunately the error if it is thrown in octokit is beyond what I can tell about, it could be some server errors from GitHub API, or it might be fixed by updating to the latest release of the 4.x version of the action (from today) with the latest octokit updates.

We might be able to improve the error by logging the whole object, instead of just the message of the error though.

[YorickH]

Hi @mikepenz,

Thanks for the input, I doubt the change in octokit will be of much value as it's only a minor security change in the release flow, anyhow still good to keep up with things.

The search continues, maybe switching to use fetchViaCommits might fix some things. We do notice these issues only on a rather large and active repository so there might be just too much to fetch.

Thanks for confirming my suspicion on being an API (or maybe network) issue, might go back to github support as they were locked into the fact we are using ARC instead of the github supported Auto Scaling Runner Set and wouldn't give support (although I doubt it would make any difference). Now I have some specific API requests I can pass.

[mikepenz]

Let me maybe also make a change to the error log when it fails. so it has the full error object printed. that could perhaps include additional details.

Given the API which appears to be the culprit. I wonder if there is some hidden crawler protection. whereas if we fetch that many pull requests that at some point the server blocks the request. As I really can't see why this request would fail for large changes. given it's paged with a limit of 100 prs per page.

And yes fetchViaCommits could be a valid alternative. It's worth to note that it does a API request per commit in the diff.

[mikepenz]

Created v4.2.2 which will log the whole error object. I hope that includes more information on what's happening

[YorickH]

@mikepenz Wow cool! Thanks but seems like I got it fixed. I moved to use fetchViaCommits and reduced the amount of PR's fetched (which was on 500 while it's often no more than 10 in reality). So probably with these 2 changes, we reduced the strain on Github's API causing the issues while maintaining the same output.

The extra logging will probably be handy if this happens again in the future.