[mihir-kandoi]

Problem

On a large release, the success step fails before it comments on any PR.

The plugin builds one getAssociatedPRs GraphQL query per 100 commits and sends all of them in parallel. A 100-commit query takes longer than GitHub's 10 second GraphQL limit, so the API returns 502/504. Depending on the response, the step fails with HttpError 504 or with TypeError: Cannot destructure property 'repository' of '(intermediate value)' as it is undefined (lib/success.js:81).

This happens on every large release of frappe/erpnext, for example v16.52.0 (708 commits) and v15.124.0 (331 commits). The release gets published, but no PR gets a comment.

Solution

• Query 25 commits per request instead of 100.
• Send the chunks one at a time, as GitHub recommends.

I replayed the plugin's query against the 708 commits of erpnext v16.52.0:

Chunk size	Mode	Result
100	parallel (current)	6 of 8 requests failed with 502/504 after about 11 s
25	parallel	flaky: one run dropped the connection, one passed
25	serial (this PR)	29 of 29 requests passed, 3 to 6 s each

Steps to reproduce

1. In a repository with a few hundred commits since the last release, run semantic-release with @semantic-release/github.
2. See that the release is published.
3. See that the success step fails with a 502/504 or the repository TypeError, and no PR gets a comment.

[barredterra]

Thanks for this PR and for the measurements. I looked into the same erpnext failure independently and opened #1335 before I saw this PR. My PR also runs the chunks one after another, so it includes the change in this PR.

I found that 25 commits per query is not always enough. On a backport branch, one commit can link to many PRs, and the current query loads all PR fields for each link. I replayed both approaches on the v15.124.0 release (332 commits) that this PR names:

	Queries	Failed	Slowest	Total
This PR (25 commits per query, all PR fields)	14	4 (502/504)	11.6 s	137 s
My PR (PR numbers first, then details for each unique PR)	20	0	3.9 s	42 s

The 332 commits link to PRs 8,105 times, but there are only 124 unique PRs. My PR first loads only the PR numbers, then loads the full fields once for each unique PR. Each query stays far below GitHub's 10-second limit. My PR also fixes the pagination of associatedPullRequests, which used an undefined variable.

If you agree, I suggest closing this PR in favour of mine. Your review there is welcome.