Current hardcoded limits can timeout Github API unexpectedly

[radicand]

Environment details

• OS: ubuntu-latest
• Node.js version: v18
• npm version: N/A
• release-please version: 16.10.0

Steps to reproduce

1. Run release-please against our current repository/branch configuration. No options are specified in the manifest presently except for specifying a simple release strategy and 4 extraFiles to update.
2. Receive an error response (below)

Notes

I can reproduce the error directly by manually querying the API call found here (above): https://github.com/googleapis/release-please/blob/08331fa555ed482f675fb3e9dd5b0a5296e200a3/src/github.ts#L442-L449 with what release-please is calling. We have had a few very large commits/merges recently and it is causing the Github API to throw an error which is preventing release-please from completing. We get the following currently:

Running release-please version: 16.10.0
❯ Fetching release-please-config.json from branch REDACTED
❯ Fetching .release-please-manifest.json from branch REDACTED
✔ Building releases
✔ Building strategies by path
❯ .: simple
❯ Fetching release-please-config.json from branch REDACTED
❯ Fetching .release-please-manifest.json from branch REDACTED
✔ Building pull requests
✔ Building strategies by path
❯ .: simple
✔ Collecting release commit SHAs
❯ release search depth: 400
❯ Fetching releases with cursor undefined
❯ Found release for path ., v3.0.0
❯ release for path: ., version: 3.0.0, sha: REDACTED[22](REDACTED)REDACTED
✔ Collecting commits since all latest releases
❯ commit search depth: 1
❯ Set(1) { 'REDACTED[23](REDACTED)REDACTED' }
❯ Fetching merge commits on branch REDACTED with cursor: undefined
Error: release-please failed: We couldn't respond to your request in time. Sorry about that. Please try resubmitting your request and contact us if the problem persists.

If I tweak the parameters however, I can get the query to succeed. Either setting a lower num value (15 works, 20 doesn't for example), or a lower maxFilesChanged (50 works, 75 doesn't), will make the query succeed.

Can these values become configurable? Alternatively, is there something we can do to short-circuit this? Setting bootstrap-sha on the most recent, uncomplicated, commit does nothing to remedy.

[rafilkmp3]

I'm having the same problem, even with the modifications you suggested i wasn't able to go through for testing. Is there a way to create some sort of checkpoint and only fetch commits from, let's say, April 01 onwards? My logs:

Running release-please version: 16.10.0
✔ Looking for latest release on branch: master with prefix: 
❯ Fetching merge commits on branch master with cursor: undefined
❯ Fetching merge commits on branch master with cursor: redacted 24
❯ Fetching merge commits on branch master with cursor: redacted 49
❯ Fetching merge commits on branch master with cursor: redacted 74
❯ Fetching merge commits on branch master with cursor: redacted 99
❯ Fetching merge commits on branch master with cursor: redacted 124
❯ Fetching merge commits on branch master with cursor: redacted [14]
❯ Fetching merge commits on branch master with cursor: redacted 174
❯ Fetching merge commits on branch master with cursor: redacted 199
❯ Fetching merge commits on branch master with cursor: redacted 224
Error: release-please failed: We couldn't respond to your request in time. Sorry about that. Please try resubmitting your request and contact us if the problem persists.

[radicand]

@rafilkmp3 to temporarily unblock us, I've installed release-please locally, edited its github.js file with these params:

    const params = {
      cursor,
      owner: this.repository.owner,
      repo: this.repository.repo,
      num: 15,
      targetBranch,
      maxFilesChanged: 50, // max is 100
    };

And ran with release-please release-pr --repo-url https://github.com/repo/path --token PAT_HERE --target-branch my-branch

I was able to generate the release this way; it's not ideal, but for anyone who needs to unblock in the interim it may help.

[rburgstaller]

is there anyone from google looking at this?

[tmayoff]

We're also running into this with one of our repos, @radicand's 'workaround' does work but is quite annoying needing to use it.

[gvillo]

same it's happening to us