Skip to content

fix(success): keep GraphQL queries for associated PRs below the timeout - #1335

Open
barredterra wants to merge 2 commits into
semantic-release:masterfrom
barredterra:fix/sequential-graphql-chunks
Open

barredterra wants to merge 2 commits into
semantic-release:masterfrom
barredterra:fix/sequential-graphql-chunks

Conversation

@barredterra

@barredterra barredterra commented Nov 6, 2026 •

Copy link
Copy Markdown

Closes #1017

Problem

For large releases, the success step can fail with 502 Bad Gateway or 504 from POST /graphql. The release and the tag already exist at that point, so no comments are posted and the next run hides the failure.

GitHub stops a GraphQL request after about 10 seconds (see #1017 (comment)). One getAssociatedPRs query asks for 100 commits × associatedPullRequests(first: 100) with all PR fields. Some of these fields are expensive (mergeable, changedFiles, commits.totalCount). The cost grows with the number of PRs for each commit. On backport branches, one commit can link to many PRs.

Measured on a public repository with a backport branch:

Query Result
100 commits, all PR fields (current) 502 / 504 after ~11 s, also when it runs alone
25 commits, all PR fields 200, ~10 s
100 commits, PR numbers only 200, ~5 s: 1,890 links, but only 64 unique PRs

Thus, smaller chunks alone do not fix the problem. The same PR is loaded again for each commit that links to it.

Fix

Load the associated PRs in two steps:

  1. Get only the PR numbers for each commit (50 commits per query).
  2. Remove duplicates, then load the full PR fields with the existing buildRelatedIssuesQuery (10 PRs per query).

Other changes:

  • inChunks runs the chunks one after another, not in parallel.
  • Related issues are also loaded 10 per query, because they use the same PR fields.
  • The issue object for successCommentCondition keeps the same fields.
  • The pagination of associatedPullRequests used an undefined variable (response). This is fixed.

Result on 200 commits of the same backport branch: 4 number queries (max 3.2 s) and 8 detail queries for 73 unique PRs (max 1.8 s). All return 200.

Tests

  • New test: 120 commits that all link to the same PR. It checks that the numbers are loaded in 3 sequential queries and the PR details in 1 query. It fails on the old code.
  • The "multipaged associatedPRs" test did not test pagination: its second mock used overwriteRoutes: true and replaced the first mock. It now checks that a PR from the second page gets a comment.
  • Other tests get one more mock for the PR details query.

For large releases, the success step sent one getAssociatedPRs query
for each 100 commits, all at the same time. GitHub can fail these
parallel queries with a timeout or a 502 error.

Run the chunks one after another.

Closes semantic-release#1017
A single getAssociatedPRs query for 100 commits can take longer than
GitHub's GraphQL timeout of about 10 seconds, even when it runs alone.
The cost grows with the number of PRs for each commit, because the
query loads all PR fields for each link. On backport branches, one
commit can link to many PRs.

Load the PRs in two steps:

1. Get only the PR numbers for each commit (50 commits per query).
2. Remove duplicates and load the full PR fields for 10 PRs per query.

Also load related issues 10 per query, because they use the same PR
fields.

This also fixes the pagination of associated PRs, which used an
undefined variable.
@barredterra barredterra changed the title fix(success): send GraphQL chunk queries one after another fix(success): keep GraphQL queries for associated PRs below the timeout Nov 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Something went wrong while executing your query. Status 502

1 participant