Remove the rateLimit selection from the MaxPullRequest GraphQL query

[kamil-gwozdz]

MaxPullRequest represents a big chunk of our graphql traffic volume and we're currently trying to optimize it.

The rateLimit portion is only used by LoggingApolloClient.query which is a high level client and it's never read by the query actual caller - _getMaxItem - shared by both MaxIssue and MaxPullRequest - returns only number. It never reads data.rateLimit.

Since other queries are requesting this field the global store should be fine and updated on any other occasion.

---

🤖 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.

[alexr00]

This is used.

[Copilot]

Pull request overview

This PR reduces GraphQL payload/field resolution work for one of the extension’s highest-volume operations (MaxPullRequest) by removing an unused top-level rateLimit { ...RateLimit } selection that the actual caller (_getMaxItem) never reads.

Changes:

• Remove the rateLimit { ...RateLimit } selection from the MaxPullRequest GraphQL query to avoid requesting unused data on a hot polling path.

Show a summary per file

File	Description
src/github/queriesShared.gql	Removes the unused rateLimit selection from the MaxPullRequest query to reduce per-request overhead.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Low

[Copilot]

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Low

[alexr00]

/AzurePipelines run

[azure-pipelines]

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.