@gitkraken/core-gitlens 0.5.109 → 0.5.110

package/dist/plus/git-github/api/github.js

@@ -9,9 +9,10 @@ import { request } from '@octokit/request';
 import { RequestError } from '@octokit/request-error';
 import { AuthenticationError, AuthenticationErrorReason, RequestClientError, RequestNotFoundError, RequestRateLimitError, } from '../../../git/errors.js';
 import { defaultIssueSort } from '../../../git/models/issue.js';
-import { PullRequestMergeMethod } from '../../../git/models/pullRequest.js';
+import { defaultPullRequestSort, PullRequestMergeMethod } from '../../../git/models/pullRequest.js';
 import { getGitHubNoReplyAddressParts } from '../../../git/remotes/github.js';
 import { effectiveIssueSort, getIssueComparator } from '../../../git/utils/issue.utils.js';
+import { getPullRequestComparator } from '../../../git/utils/pullRequest.utils.js';
 import { createRevisionRange, getRevisionRangeParts, isRevisionRange, isSha, } from '../../../git/utils/revision.utils.js';
 import { chunk } from '../../../utils/array.js';
 import { base64 } from '../../../utils/base64.js';
@@ -51,10 +52,17 @@ const requestRetryMaxDelay = 2000; // ms
 const accountResolveBatchSize = 25;
 // Pull-request search selects the full PR fragment (reviews, requests, refs, commits, etc.),
 // which makes GitHub reject broad 100-node searches with `Resource limits for this query
-// exceeded` on large repositories. Thirty keeps the default within that GraphQL cost budget
-// while callers that know their scope is cheap can still opt into the supported 100-node max.
+// exceeded` on large repositories. Thirty keeps the default within that GraphQL cost budget;
+// the 100-node maximum the connection accepts is for the lite shape, whose per-node cost is a
+// fraction of it. The budget is per DOCUMENT, and one document holds every relationship × state
+// facet, so the worst case scales with the facet count (five relationships × four states = 20).
 const defaultPullRequestSearchPageSize = 30;
 const maxPullRequestSearchPageSize = 100;
+// Pages `searchMyPullRequests` drains for a caller that wants a whole list rather than a page.
+// Four reduced pages cover more than the single 100-node page this read served before it paged,
+// so the smaller page costs coverage nowhere; it bounds an unbounded drain on a read whose
+// consumers (Launchpad, the Graph pull-request panel) block on it.
+const maxMyPullRequestSearchPages = 4;
 function isRetryableTransientError(ex) {
     // An aborted request is rethrown as the original `AbortError` (not a `RequestError`), so it is
     // excluded here. octokit maps a fetch/network failure to a `RequestError` with status 500 and
@@ -153,6 +161,24 @@ repository {
 	viewerPermission
 }
 `;
+/**
+ * One review's fields, shared by `latestReviews` and `viewerLatestReview`. The two selections must stay
+ * identical: `fromGitHubPullRequest` merges the viewer's review into the capped `latestReviews` window and
+ * dedups by `id`, so a field present in only one of them would produce rows that differ by where they came
+ * from rather than by what they are.
+ */
+const gqlPullRequestReviewFragment = `
+id
+author {
+	login
+	avatarUrl(size: $avatarSize)
+	url
+}
+state
+commit {
+	oid
+}
+`;
 const gqlPullRequestFragment = `
 ${gqlPullRequestLiteFragment}
 additions
@@ -172,14 +198,12 @@ mergedBy {
 reviewDecision
 latestReviews(first: 25) {
 	nodes {
-		author {
-			login
-			avatarUrl(size: $avatarSize)
-			url
-		}
-		state
+		${gqlPullRequestReviewFragment}
 	}
 }
+viewerLatestReview {
+	${gqlPullRequestReviewFragment}
+}
 reviewRequests(first: 25) {
 	nodes {
 		asCodeOwner
@@ -2161,14 +2185,21 @@ export class GitHubApi {
      * One page of the current user's pull requests, filtered by state and optionally by an explicit
      * relationship qualifier. Backs the PR sweeps, which drain it page by page.
      *
-     * Ordering is part of the contract, not an option: always `sort:updated` (most recently updated first),
-     * matching {@link searchPullRequestsPage}. A caller that stops before `hasMore` clears — every sweep with a
+     * Ordering is part of the contract, not an option: always `sort:updated` (most recently updated first), which is
+     * {@link searchPullRequestsPage}'s DEFAULT rather than its only order — that read takes a `criteria.sort`, this
+     * one does not, because a sweep's recency window is what its page budget is defined against. A caller that stops
+     * before `hasMore` clears — every sweep with a
      * page budget — therefore retains a well-defined recency window instead of an arbitrary slice of GitHub's
      * relevance ranking.
      */
     async searchMyPullRequestsPage(provider, token, options, cancellation) {
         const scope = getScopedLogger();
-        const limit = Math.min(100, this.config.getLaunchpadQueryLimit?.() ?? 100);
+        // The page follows the projection rather than being a separate decision: the full fragment is what GitHub
+        // rejects at 100 nodes (see `defaultPullRequestSearchPageSize`), so every read that selects it pages at the
+        // reduced size, and only the lite shape asks for the maximum. A caller that wants a whole list pages for it
+        // — see `searchMyPullRequests`.
+        const configuredLimit = this.config.getLaunchpadQueryLimit?.() ?? maxPullRequestSearchPageSize;
+        const limit = Math.min(options?.summary === true ? maxPullRequestSearchPageSize : defaultPullRequestSearchPageSize, configuredLimit);
         try {
             const query = `query searchMyPullRequests(
 		$search: String!
@@ -2247,8 +2278,36 @@ export class GitHubApi {
             throw this.handleException(ex, provider, scope, options?.silent);
         }
     }
+    /**
+     * The whole list rather than a page: this read has no cursor to hand back (its `IntegrationResult<T[]>` return
+     * has no paging channel at all), so it drains up to {@link maxMyPullRequestSearchPages} pages itself.
+     *
+     * Draining instead of taking one page is what lets the full projection page at the reduced size everywhere
+     * (see the `limit` in {@link searchMyPullRequestsPage}): a single page would otherwise have to ask for 100
+     * nodes of the selection GitHub rejects at that size, purely because this caller cannot resume. Ordering is
+     * `sort:updated`, so the pages compose into a defined window rather than a shifting relevance ranking, and the
+     * drain stops as soon as GitHub reports no next page.
+     */
     async searchMyPullRequests(provider, token, options, cancellation) {
-        return (await this.searchMyPullRequestsPage(provider, token, options, cancellation)).values;
+        const values = [];
+        // The searches behind one page can overlap (a PR can be authored by and review-requested from the same
+        // user), and a later page can repeat a row an earlier one already served if the PR was updated mid-drain.
+        const seen = new Set();
+        let cursor;
+        for (let page = 0; page < maxMyPullRequestSearchPages; page++) {
+            const result = await this.searchMyPullRequestsPage(provider, token, { ...options, cursor: cursor }, cancellation);
+            for (const pr of result.values) {
+                if (seen.has(pr.url))
+                    continue;
+                seen.add(pr.url);
+                values.push(pr);
+            }
+            // A missing or repeated cursor with `hasMore` would loop on the same page forever.
+            if (!result.hasMore || result.cursor == null || result.cursor === cursor)
+                break;
+            cursor = result.cursor;
+        }
+        return values;
     }
     /**
      * The current user's issues: authored ∪ assigned ∪ mentioned, each its own aliased search behind one composite
@@ -2431,6 +2490,64 @@ export class GitHubApi {
             throw this.handleException(ex, provider, scope);
         }
     }
+    /**
+     * The PR twin of {@link countIssues}: counts pull requests for several scopes in ONE request via aliased
+     * `search` fields selecting only `issueCount` with `first: 0`. Same positional/undefined contract as the issue
+     * count.
+     *
+     * The one difference is states. {@link toGitHubPullRequestSearchFacets} fans a scope's states out into one
+     * `search` each, so this reports the count the SAME way {@link searchPullRequestsPage} reports its total — the
+     * LARGEST facet's `issueCount`, not their sum: the result ceiling applies per search, so the max is what
+     * `exceedsProviderLimit` compares against, and summing would claim a total the read never surfaces. Relationships
+     * are OR-ed and can't be a single count; the facade refuses a multi-relationship scope, so at most one is here.
+     */
+    async countPullRequests(provider, token, scopes, options, cancellation) {
+        const scope = getScopedLogger();
+        if (scopes.length === 0)
+            return [];
+        // Each scope expands to one query string per state facet (all sharing its single relationship, which the
+        // facade guarantees). A scope's count is the MAX across its facets — mirroring searchPullRequestsPage's
+        // totalCount — so the aliases stay grouped by scope and are reduced after the response.
+        const scopeQueries = scopes.map(s => {
+            const scopeQualifiers = toGitHubIssueSearchScopeQualifiers(s.org, s.repos);
+            return toGitHubPullRequestSearchFacets(s.criteria).map(f => [...scopeQualifiers, ...f.qualifiers].join(' '));
+        });
+        // Aliases are positional and generated (`s${scope}f${facet}`): a caller's key is arbitrary text and would
+        // break the document, so results are reduced back to one count per scope by index.
+        const aliased = scopeQueries.flatMap((queries, si) => queries.map((query, fi) => ({ alias: `s${si}f${fi}`, query: query })));
+        const params = aliased.map(a => `$${a.alias}: String!`).join('\n\t\t\t\t');
+        // `first: 0` is what makes this cheap — `issueCount` alone, no nodes over the wire.
+        const fields = aliased
+            .map(a => `${a.alias}: search(query: $${a.alias}, type: ISSUE, first: 0) { issueCount }`)
+            .join('\n\t\t\t\t');
+        const query = `query countPullRequests(
+				${params}
+			) {
+				${fields}
+			}`;
+        const variables = { baseUrl: options?.baseUrl };
+        for (const a of aliased) {
+            variables[a.alias] = a.query;
+        }
+        try {
+            const rsp = await this.graphql(provider, token, query, variables, scope, cancellation);
+            if (rsp == null)
+                return scopes.map(() => undefined);
+            return scopeQueries.map((queries, si) => {
+                let max;
+                for (let fi = 0; fi < queries.length; fi++) {
+                    const count = rsp[`s${si}f${fi}`]?.issueCount;
+                    if (count != null) {
+                        max = max == null ? count : Math.max(max, count);
+                    }
+                }
+                return max;
+            });
+        }
+        catch (ex) {
+            throw this.handleException(ex, provider, scope);
+        }
+    }
     /**
      * The aliased-search engine behind every GitHub issue search: one GraphQL request carrying N independently
      * cursored `search` fields, `@include`-gated so an exhausted or unrequested one costs nothing.
@@ -2646,8 +2763,11 @@ export class GitHubApi {
      * every active relationship × state facet, so one HTTP request serves one page even when the logical search is
      * a union. The cursor preserves each facet's continuation plus the positional page.
      *
-     * Ordering is always most-recently-updated-first, and user text is sanitized before it reaches the provider
-     * query. See {@link toGitHubPullRequestSearchFacets}.
+     * Ordering is `criteria.sort`, defaulting to most-recently-updated-first — the order this read served before it
+     * was expressible. It is requested of the provider AND re-applied to the merged page, because the page is a
+     * union of facets and no per-facet server order describes it. The sort is part of the cursor fingerprint, so
+     * changing it invalidates a threaded cursor exactly as changing the text or the scope does. User text is
+     * sanitized before it reaches the provider query. See {@link toGitHubPullRequestSearchFacets}.
      */
     async searchPullRequestsPage(provider, token, options, cancellation) {
         const scope = getScopedLogger();
@@ -2758,7 +2878,15 @@ export class GitHubApi {
                     }
                 }
             }
-            pullRequests.sort((a, b) => b.updatedDate.getTime() - a.updatedDate.getTime());
+            // The PR path re-sorts the merged page rather than trusting the per-facet server order — GitHub's
+            // server-side PR sort has been unreliable (the per-branch path re-sorts for the same reason), and the
+            // union of several facets is unordered regardless. The key was validated against
+            // `githubPullRequestSearchCapabilities.sorts` upstream, so its comparator is always defined for a PR
+            // shape; the guard only guards the unreachable case rather than inventing an order for it.
+            const comparator = getPullRequestComparator(options?.criteria?.sort ?? defaultPullRequestSort);
+            if (comparator != null) {
+                pullRequests.sort(comparator);
+            }
             const values = [
                 ...uniqueBy(pullRequests, pr => pr.url, (original, _current) => original),
             ];
@@ -3205,6 +3333,9 @@ __decorate([
 __decorate([
     trace({ args: (provider, token) => ({ provider: provider.name, token: `<token:${token.microHash}>` }) })
 ], GitHubApi.prototype, "countIssues", null);
+__decorate([
+    trace({ args: (provider, token) => ({ provider: provider.name, token: `<token:${token.microHash}>` }) })
+], GitHubApi.prototype, "countPullRequests", null);
 __decorate([
     trace({ args: (provider, token) => ({ provider: provider.name, token: `<token:${token.microHash}>` }) })
 ], GitHubApi.prototype, "searchPullRequestsPage", null);