Remove the unused rateLimit selection from the MaxPullRequest GraphQL query by kamil-gwozdz · Pull Request #8812 · microsoft/vscode-pull-request-github · GitHub
Skip to content

Remove the unused rateLimit selection from the MaxPullRequest GraphQL query#8812

Draft
kamil-gwozdz wants to merge 1 commit into
microsoft:mainfrom
kamil-gwozdz:kamil-gwozdz/maxpullrequest-drop-ratelimit
Draft

Remove the unused rateLimit selection from the MaxPullRequest GraphQL query#8812
kamil-gwozdz wants to merge 1 commit into
microsoft:mainfrom
kamil-gwozdz:kamil-gwozdz/maxpullrequest-drop-ratelimit

Conversation

@kamil-gwozdz

@kamil-gwozdz kamil-gwozdz commented Jun 25, 2026

Copy link
Copy Markdown

TBD — author to fill in.


🤖 AI-generated description

What changed

This PR removes the top-level rateLimit { ...RateLimit } selection from the MaxPullRequest query in src/github/queriesShared.gql. No other queries are touched — MaxIssue and the ~28 other operations that select rateLimit keep it, and the shared fragment RateLimit on RateLimit remains in use elsewhere, so it stays defined.

Why

MaxPullRequest is a high-frequency, per-repo change-detection poll — one of the hottest GraphQL operations the extension emits. Its handler _getMaxItem (src/github/githubRepository.ts) reads only data.repository.issues.edges[0].node.number (the latest PR number) and never touches data.rateLimit. Selecting rateLimit on every poll asks the GitHub GraphQL API to resolve an extra top-level field whose result is discarded. Dropping it trims that unused resolver from the highest-volume query.

Scope & safety

  • No functional impact. The only generic consumer of the field is RateLogger.logRateLimit (src/github/loggingOctokit.ts), invoked by the LoggingApolloClient.query wrapper on every query. It reads resolvedResult?.data?.rateLimit and already degrades gracefully when the field is absent: it falls back to ?? 5000 / ?? 1000 defaults. As a result, removing the selection produces no spurious "Unexpectedly low rate limit" warning, and the pr.lowRateLimitRemaining telemetry simply does not fire for this single call path.
  • Rate-limit visibility is preserved. Every other query that selects rateLimit continues to report it, so overall rate-limit monitoring and telemetry are unaffected.
  • No type changes needed. _getMaxItem does not reference rateLimit, and the MaxIssueResponse interface still applies to MaxIssue. The .gql files are loaded at build time via the graphql-tag webpack loader; there is no committed generated TypeScript to regenerate.

Notes

  • The change is intentionally surgical: MaxPullRequest only, leaving MaxIssue and all other rateLimit-selecting queries as-is.
  • Because logRateLimit already handles the missing-field case, this is a safe no-op for behavior — it only reduces what MaxPullRequest asks the API to resolve.

MaxPullRequest is a very high-frequency change-detection poll, and its
handler (_getMaxItem) only reads the latest PR number — it never consumes
the rateLimit block. The only generic consumer (RateLogger.logRateLimit)
already degrades gracefully when rateLimit is absent (it falls back to the
?? 5000 / ?? 1000 defaults and other queries still report it), so removing
this top-level field from the hottest query has no functional impact.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@kamil-gwozdz kamil-gwozdz changed the title Drop unused rateLimit selection from the MaxPullRequest query Remove the unused rateLimit selection from the MaxPullRequest GraphQL query Jun 25, 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.

1 participant