@gitkraken/core-gitlens 0.5.113 → 0.5.115

package/src/plus/integrations/reads/broaden.ts

@@ -1,9 +1,11 @@
 import type { IssueShape } from '../../../git/models/issue.js';
+import { effectiveIssueSort } from '../../../git/utils/issue.utils.js';
 import { mapBounded } from '../../../utils/promise.js';
 import { mergeAssessmentInto } from '../collectionMetadata.js';
 import type { IntegrationIds } from '../constants.js';
 import { providerFanOutConcurrency } from '../constants.js';
 import type { ProviderBroadenOrg } from '../manager.js';
+import type { GitHostIntegration } from '../models/gitHostIntegration.js';
 import type { ProviderReposInput } from '../providers/models.js';
 import type { ProviderBroadenResult, ProviderWarning } from '../results.js';
 import { appendDedupedWarning } from '../results.js';
@@ -13,32 +15,78 @@ import type { ProviderReadContext } from './context.js';
 import type { BroadenIssuesExhaustedOrg, BroadenIssuesOrgCursor } from './cursors.js';
 import { getBroadenIssuesCursor, isBroadenIssuesOrgExhausted, toBroadenIssuesCursor } from './cursors.js';
 import { drainRepositories, runCaptured } from './drains.js';
-import { resolveContinuation, toProviderPageInfo } from './paging.js';
-import { gitHostOnlySurfaceWarning, issuesUnsupportedWarning, noConnectionWarning, otherWarning } from './warnings.js';
+import { resolveIssueSearchScope, supportsFilteredIssueSearch } from './filters.js';
+import { resolveContinuation, toProviderPageInfo, usableCursor } from './paging.js';
+import {
+	gitHostOnlySurfaceWarning,
+	issueSearchCapResultWarning,
+	issuesUnsupportedWarning,
+	noConnectionWarning,
+	otherWarning,
+	truncationWarning,
+	unsupportedIssueSearchCriteriaWarning,
+} from './warnings.js';
 
 /**
- * The issue-broadening fan-out: per org, drain that org's repositories, then read every visible issue in them.
+ * The issue-broadening fan-out: every visible issue across a set of orgs, one page at a time.
  *
  * What makes this its own read rather than a variant of `listIssuesPage` is that one logical page spans several
  * provider positions — one per org — so its continuation is a per-org cursor BUNDLE (see `cursors.ts`) and its
  * failure attribution is per provider across those orgs. Both are the reason a page number alone can't address a
  * later page, and why {@link broadenIssues} walks prior pages itself when given only `page`.
  *
- * SUPERSEDED for a caller that already knows its repositories: `searchIssuesPage({ repos, criteria })` answers
- * the same question in one request per page, with no repository drain and no route through the SDK read whose
- * over-limit recovery walk can spend up to 128 requests. This read stays for "fan out across these orgs,
- * whatever repos they contain", whose per-provider attribution the single-provider search doesn't produce.
+ * Each org slice runs on ONE OF TWO ENGINES, chosen by what the provider declares (#5804):
+ * - the org-scoped FILTERED SEARCH where the provider has one (GitHub/GHE): one request per page, no repositories
+ *   needed at all, since the search reaches the scope by naming the org;
+ * - the REPOSITORY DRAIN plus the SDK's repo-scoped read where it doesn't (Azure DevOps, GitLab): up to 100
+ *   requests to enumerate the org, and a read whose over-limit recovery walk can spend 128 more per repository
+ *   and still return an incomplete set.
  *
- * If you migrate a caller, note the semantics carefully: broadening means ALL VISIBLE — it passes
- * `includeAllAssignees: true`, which resolves to no assignee constraint at all, so unassigned issues ARE
- * included. The equivalent is an OMITTED `relationships`, not `['any-assignee']`: `assignee:*` means "has some
+ * Measured by running this read against the live API, three times per engine per org (median shown; each
+ * engine returned a byte-identical result set on all three, so the sets below are not sampling noise):
+ *
+ * | | repo drain + SDK read | org-scoped search |
+ * | --- | --- | --- |
+ * | BELOW the ceiling (146 issues) | 9.3s, 11 requests, 146 issues | 6.2s, 2 requests, 146 issues |
+ * | ABOVE it (1.475 issues, 217 repos) | 111s, 133 requests, 1.118 issues | 40s, 10 requests, 1.000 issues |
+ * | ...of the 1.000 most recently updated | 644 | 1.000 |
+ * | ...omissions reported | 99 × `recovery-budget`, no count | 1, carrying `totalCount: 1474` |
+ *
+ * BELOW the ceiling the two return the IDENTICAL SET (verified as set equality), so there the swap is a straight
+ * saving and nothing else. ABOVE it they return DIFFERENT SETS — overlapping on 644 items, so the divergence is
+ * not confined to the edge.
+ *
+ * Above the ceiling the search returns FEWER items and is nonetheless the more useful of the two, which is the
+ * whole reason to prefer it: its 1.000 are exactly the 1.000 most recently updated (again set equality against a
+ * ceiling-free enumeration, not a count), whereas the SDK read's 1.118 are an arbitrary subset — 474 of them from
+ * beyond that window, at the cost of omitting 356 issues that ARE in it. Its recovery walk does not close the gap
+ * it spends the budget on: all 99 of its omissions were exhausted budget.
+ *
+ * The second difference is what a consumer can SAY about the gap. At the ceiling the search succeeds and reports
+ * one quantified omission (`issueSearchCapResultWarning` carries `totalCount`, `limit` and the order the window
+ * was selected under), so a consumer can render "1.474 matched, showing the 1.000 most recently updated". The
+ * SDK read reports one `recovery-budget` omission per exhausted repository, none of which carries how many issues
+ * were missed — incompleteness that can be announced but not quantified.
+ *
+ * Note the time saving is the SMALLER half of this: 1.5× below the ceiling and 2.8× above it, against 5.5× and
+ * 13.3× fewer requests. The request count is what matters for a rate limit shared with every other read.
+ *
+ * The public surface is the SAME on both: the options, the per-org cursor bundle, the `ProviderAttribution`
+ * split, the warning dedupe and the return type. A consumer needs to know which engine ran only insofar as the
+ * warnings say so.
+ *
+ * Broadening means ALL VISIBLE, and each engine expresses that differently — `includeAllAssignees: true` on the
+ * SDK read, an OMITTED `relationships` on the search. Both resolve to no assignee constraint at all, so
+ * unassigned issues ARE included. The search's equivalent is NOT `['any-assignee']`: `assignee:*` means "has some
  * assignee" and would silently exclude every unassigned issue, which is the opposite of broadening.
  *
  * Takes no `sort`, unlike `listIssuesPage` and `searchIssuesPage`. One logical page here spans several orgs, each
  * at its own provider position in a cursor bundle, so honoring an order across them would need a k-way merge with
  * a buffer per org rather than a sort of what arrived — the page is a slice of several independent walks, not a
- * union of one round's results. `searchIssuesPage({ repos, criteria: { sort } })` answers the ordered version of
- * this question for a caller that knows its repositories, and is already the recommended migration above.
+ * union of one round's results. The search engine still orders each org's OWN query (it must: a ceiling policy of
+ * "the N most recent" is only correct under a guaranteed order), so a slice is ordered where the merged page is
+ * not. `searchIssuesPage({ repos, criteria: { sort } })` answers the ordered version of this question for a
+ * caller that knows its repositories.
  */
 
 export interface BroadenIssuesOptions {
@@ -276,7 +324,210 @@ async function traverseToRequestedPage(
 	};
 }
 
-/** Reads one org's visible issues: drain the org's repos, then read the issues across them. */
+/**
+ * One org's issues as either engine below reports them, normalized to the single shape {@link readOrgSlice}'s
+ * bookkeeping consumes.
+ *
+ * The two engines return different envelopes — the SDK read's `PagedResult` + `paging`, the search's flat page —
+ * and normalizing HERE rather than per engine is what keeps the continuation, retry, attribution and exhaustion
+ * rules literally the same code on both paths. A second copy of those rules per engine is how one path would come
+ * to advertise a continuation the other calls terminal.
+ */
+interface OrgIssuesRead {
+	/** The page the provider served, or `undefined` when the read returned none (which `warning` explains). */
+	value?: { items: IssueShape[]; hasMore: boolean; cursor?: string; truncated: boolean };
+	/** The read's own failure. Already included in `warnings`; carried separately because the retry rules key off it. */
+	warning?: ProviderWarning;
+	/** Everything the engine produced, the read's own failure included. */
+	warnings: ProviderWarning[];
+	fetchFailed: boolean;
+	truncated: boolean;
+	/**
+	 * The engine established there is NOTHING to read for this org — the repository drain returned no
+	 * repositories — so the slice is terminal and empty. Distinct from `value == null`, which means a read WAS
+	 * issued and came back with no page, and so is a position to retry.
+	 */
+	nothingToRead?: boolean;
+}
+
+/**
+ * Whether this org can be read through the FILTERED issue search instead of the repository drain.
+ *
+ * Two conditions, and the second is not a formality: an empty org name is dropped by the provider's scope
+ * translation rather than rejected, which would leave a search of the WHOLE HOST — so the scope is validated
+ * through {@link resolveIssueSearchScope}, the same rule `searchIssuesPage` refuses on, rather than by an
+ * `org.name.length > 0` written here and free to drift from it.
+ */
+function canSearchOrgIssues(org: ProviderBroadenOrg): boolean {
+	return (
+		supportsFilteredIssueSearch(org.providerId) &&
+		resolveIssueSearchScope(undefined, org.name, undefined).rejection == null
+	);
+}
+
+/**
+ * The org-scoped filtered search: ONE request per page, whatever the org contains.
+ *
+ * Replaces the drain + SDK read for every provider that declares a filtered issue search — the repository drain
+ * costs up to 100 requests per org, and the SDK's repo-scoped read past GitHub's result ceiling enters a
+ * per-repository recovery walk that can spend 128 more and still return an incomplete set. Measured on an org
+ * past that ceiling: 133 requests and 111s, against this read's 10 and 40s. The search reaches the same scope by
+ * NAMING the org, so it needs no repositories at all.
+ *
+ * It is also the more COMPLETE of the two over the window a consumer reads first, despite returning fewer items —
+ * see the module docstring's table for the measurement and why that is not a contradiction.
+ *
+ * `criteria` is omitted entirely, and each half of that is deliberate:
+ * - `relationships` OMITTED is what drops the assignee constraint, which is the substitution `includeAllAssignees:
+ *   true` performs on the read this replaces. NOT `['any-assignee']`, which means "assigned to somebody" and would
+ *   exclude every unassigned issue — the opposite of broadening.
+ * - every other criterion left unset resolves to the provider's own default, which is the state this read already
+ *   served (open issues only, archived repositories excluded).
+ *
+ * At the result ceiling this SUCCEEDS and reports how many matched instead of walking for the rest — see the
+ * ceiling warning below.
+ */
+async function readOrgIssuesViaSearch(
+	integration: GitHostIntegration,
+	org: ProviderBroadenOrg,
+	domain: string | undefined,
+	cursor: string | undefined,
+): Promise<OrgIssuesRead> {
+	const connectionId = org.connectionId;
+	const captured = await runCaptured(
+		org.providerId,
+		domain,
+		connectionId,
+		() => integration.searchIssuesPageResult({ org: org.name, cursor: cursor }, undefined, connectionId),
+		{ warnOnMissingSession: true },
+	);
+
+	// A provider that declares the capability but implements no search hook answers `undefined` with no error.
+	// Reported as the explicit unsupported failure rather than left as a silent empty page, so it can't be mistaken
+	// for an org with no issues — and as the read's `warning`, so the slice treats it as the read failure it is.
+	const warning =
+		captured.warning ??
+		(captured.value == null
+			? unsupportedIssueSearchCriteriaWarning(org.providerId, domain, connectionId, {
+					reason: 'unsupported-search',
+				})
+			: undefined);
+	const warnings = warning != null ? [warning] : [];
+
+	let value: OrgIssuesRead['value'];
+	if (captured.value != null) {
+		const page = captured.value;
+		value = {
+			items: page.values,
+			hasMore: page.hasMore,
+			cursor: usableCursor(page.cursor),
+			truncated: page.truncated,
+		};
+		// The result ceiling is the one incompleteness this read can QUANTIFY, so it carries the total rather than
+		// a bare "may be incomplete" — which is what lets a consumer say "1.474 matched, showing the 1.000 most
+		// recently updated" instead of silently serving a truncated list. Only when nothing else already explained
+		// the incompleteness, and only the ceiling gets the number: any other cause falls back to the generic
+		// wording rather than reporting a limit it didn't hit. `exhausted`: nothing this read exposes would return
+		// the withheld items.
+		if (page.truncated && warnings.length === 0) {
+			warnings.push(
+				issueSearchCapResultWarning(
+					org.providerId,
+					domain,
+					connectionId,
+					page.totalCount,
+					effectiveIssueSort(undefined),
+				) ?? truncationWarning(org.providerId, domain, connectionId, 'Issue search', 'exhausted'),
+			);
+		}
+	}
+
+	return { value: value, warning: warning, warnings: warnings, fetchFailed: false, truncated: false };
+}
+
+/**
+ * The original engine: drain the org's repositories, then read the issues across them.
+ *
+ * Kept for a provider that declares NO filtered issue search (Azure DevOps, GitLab), where refusing the org would
+ * be a regression rather than a saving. Its cost, and the arbitrary subset it serves past the result ceiling, are
+ * what {@link readOrgIssuesViaSearch} exists to avoid — see the module docstring's measurement. Those providers
+ * keep both, because on them there is nothing better to switch to.
+ */
+async function readOrgIssuesViaRepoDrain(
+	integration: GitHostIntegration,
+	org: ProviderBroadenOrg,
+	domain: string | undefined,
+	cursor: string | undefined,
+): Promise<OrgIssuesRead> {
+	const connectionId = org.connectionId;
+	const reposDrain = await drainRepositories(
+		integration,
+		org.providerId,
+		domain,
+		org.name,
+		undefined,
+		connectionId,
+		100,
+	);
+	const warnings: ProviderWarning[] = [...reposDrain.warnings];
+
+	const repos: ProviderReposInput = reposDrain.repos.map(r => ({ ...r }));
+	if (repos.length === 0) {
+		return {
+			warnings: warnings,
+			fetchFailed: reposDrain.fetchFailed,
+			truncated: reposDrain.truncated,
+			nothingToRead: true,
+		};
+	}
+
+	// Broaden = "all visible": drop the assigned-to-me filter so unassigned issues are included.
+	const captured = await runCaptured(
+		org.providerId,
+		domain,
+		connectionId,
+		() =>
+			// Normalized shapes seam, uniform with listIssuesPage.
+			integration.getMyIssuesForReposAsShapesResult(
+				repos,
+				{ includeAllAssignees: true, cursor: cursor },
+				connectionId,
+			),
+		{ warnOnMissingSession: true },
+	);
+	if (captured.warning != null) {
+		warnings.push(captured.warning);
+	}
+	const assessment = mergeAssessmentInto(warnings, org.providerId, domain, connectionId, captured.value?.metadata);
+
+	let value: OrgIssuesRead['value'];
+	if (captured.value != null) {
+		const paged = toProviderPageInfo(captured.value.values.length, captured.value.paging);
+		value = {
+			items: captured.value.values,
+			hasMore: paged.hasMore,
+			cursor: paged.cursor,
+			// Carry a truncation signal from the issue read too: a provider that couldn't confirm it drained a
+			// repo (`paging.truncated`) means this org's issues may be incomplete, on top of any repo-drain
+			// truncation already captured above.
+			truncated: paged.truncated || assessment.truncated,
+		};
+	}
+
+	return {
+		value: value,
+		warning: captured.warning,
+		warnings: warnings,
+		fetchFailed: reposDrain.fetchFailed || assessment.fetchFailed,
+		truncated: reposDrain.truncated,
+	};
+}
+
+/**
+ * Reads one org's visible issues, through the org-scoped filtered search where the provider has one and through
+ * the repository drain where it doesn't. Everything below the engine — the position, the retry slot, the
+ * attribution and the exhaustion mark — is the same on both paths.
+ */
 async function readOrgSlice(
 	ctx: ProviderReadContext,
 	options: BroadenIssuesOptions,
@@ -362,71 +613,32 @@ async function readOrgSlice(
 	await ctx.forceRefreshIfRequested(integration, options.forceSync, connectionId);
 
 	const domain = ctx.domainForRead(integration, org.providerId, connectionId, requestedDomain);
-	const reposDrain = await drainRepositories(
-		integration,
-		org.providerId,
-		domain,
-		org.name,
-		undefined,
-		connectionId,
-		100,
-	);
-	const warnings: ProviderWarning[] = [...reposDrain.warnings];
-	const fetchFailed = reposDrain.fetchFailed;
-	const truncated = reposDrain.truncated;
-
-	const repos: ProviderReposInput = reposDrain.repos.map(r => ({ ...r }));
-	if (repos.length === 0) {
-		return barrenSlice(warnings, { fetchFailed: fetchFailed, truncated: truncated });
-	}
-
-	// Broaden = "all visible": drop the assigned-to-me filter so unassigned issues are included.
 	const cursor = getBroadenIssuesCursor(options.cursor, org, page, options.orgs.length);
-	const issuesCaptured = await runCaptured(
-		org.providerId,
-		domain,
-		connectionId,
-		() =>
-			// Normalized shapes seam, uniform with listIssuesPage.
-			integration.getMyIssuesForReposAsShapesResult(
-				repos,
-				{ includeAllAssignees: true, cursor: cursor },
-				connectionId,
-			),
-		{ warnOnMissingSession: true },
-	);
-	if (issuesCaptured.warning != null) {
-		warnings.push(issuesCaptured.warning);
+	const read = canSearchOrgIssues(org)
+		? await readOrgIssuesViaSearch(integration, org, domain, cursor)
+		: await readOrgIssuesViaRepoDrain(integration, org, domain, cursor);
+	if (read.nothingToRead === true) {
+		return barrenSlice(read.warnings, { fetchFailed: read.fetchFailed, truncated: read.truncated });
 	}
-	const issuesAssessment = mergeAssessmentInto(
-		warnings,
-		org.providerId,
-		domain,
-		connectionId,
-		issuesCaptured.value?.metadata,
-	);
-	let issuesFetchFailed =
-		issuesAssessment.fetchFailed || (issuesCaptured.warning != null && issuesCaptured.value == null);
+
+	const warnings = read.warnings;
+	let issuesFetchFailed = read.fetchFailed || (read.warning != null && read.value == null);
 	const items: IssueShape[] = [];
 	let hasMore = false;
 	let nextCursor: string | undefined;
 	let retryPage: number | undefined;
-	// Carry a truncation signal from the issue read too: a provider that couldn't confirm it drained
-	// a repo (`paging.truncated`) means this org's issues may be incomplete, on top of any repo-drain
-	// truncation already captured above.
 	let issuesTruncated = false;
-	if (issuesCaptured.value != null) {
-		items.push(...issuesCaptured.value.values);
-		const paged = toProviderPageInfo(issuesCaptured.value.values.length, issuesCaptured.value.paging);
+	if (read.value != null) {
+		items.push(...read.value.items);
 		// An org that reports another page but no usable cursor can't be resumed: it would neither be
 		// recorded in the composite cursor nor marked exhausted, so the next round would re-read its
 		// page 1 and repeat every issue. Treat it as terminal-but-incomplete (which also marks the org
 		// exhausted below, since `exhausted` keys off `!hasMore`).
-		const continuation = resolveContinuation(paged, undefined);
+		const continuation = resolveContinuation(read.value, undefined);
 		hasMore = continuation.hasMore;
 		nextCursor = continuation.cursor;
-		issuesTruncated = continuation.truncated || issuesAssessment.truncated;
-	} else if (issuesCaptured.warning != null || cursor != null) {
+		issuesTruncated = continuation.truncated;
+	} else if (read.warning != null || cursor != null) {
 		// Keep the exact position that failed. Without this retry cursor a multi-org continuation would
 		// omit this org from the bundle, then synthesize the next numbered page and silently skip the
 		// failed page. The synthesized page cursor is also actionable for a first-page cursor-only read:
@@ -435,7 +647,7 @@ async function readOrgSlice(
 		// query request it forever. Healthy sibling continuations set `hasMore` independently.
 		if (cursor != null) {
 			nextCursor = cursor;
-			if (issuesCaptured.warning == null) {
+			if (read.warning == null) {
 				appendDedupedWarning(
 					warnings,
 					otherWarning(
@@ -456,7 +668,7 @@ async function readOrgSlice(
 	return {
 		items: items,
 		warnings: warnings,
-		broadenedProviderIds: issuesCaptured.value != null ? [org.providerId] : [],
+		broadenedProviderIds: read.value != null ? [org.providerId] : [],
 		providerId: org.providerId,
 		org: org.name,
 		connectionId: connectionId,
@@ -466,8 +678,8 @@ async function readOrgSlice(
 		hasMore: hasMore,
 		// Exhausted once a successful read reports no more pages — recorded in the cursor so later
 		// rounds skip it while other orgs keep paging.
-		exhausted: issuesCaptured.value != null && !hasMore,
-		fetchFailed: fetchFailed || issuesFetchFailed,
-		truncated: truncated || issuesTruncated,
+		exhausted: read.value != null && !hasMore,
+		fetchFailed: issuesFetchFailed,
+		truncated: read.truncated || issuesTruncated,
 	};
 }

package/src/plus/integrations/reads/filters.ts

@@ -196,6 +196,20 @@ export type IssueSearchCriteriaRejection =
 	/** `any-assignee` and `unassigned` partition the scope between them; asking for both asks for nothing. */
 	| { reason: 'contradictory-relationships' };
 
+/**
+ * Whether a provider exposes the FILTERED issue search at all — the one predicate a caller can check BEFORE
+ * building criteria, so a read that would only be refused is never issued.
+ *
+ * The same test {@link resolveIssueSearchCriteria} makes for its `unsupported-search` rejection, named rather
+ * than re-derived at each call site: a caller writing `supportedIssueSearch != null` itself is a copy free to
+ * disagree with the validator about what "has a search" means. `broadenIssues` reads it to pick its engine —
+ * the org-scoped search where there is one, the repository drain where there isn't — which is a CHOICE rather
+ * than a refusal, so it needs the predicate without the rejection.
+ */
+export function supportsFilteredIssueSearch(id: IntegrationIds): boolean {
+	return providersMetadata[id]?.supportedIssueSearch != null;
+}
+
 /**
  * Validates a filtered issue search's criteria against {@link ProviderMetadata.supportedIssueSearch}.
  *
@@ -311,6 +325,23 @@ export type IssueSearchScopeRejection =
 	/** Repositories given as ids. A search names repositories by PATH, so ids can't express a scope. */
 	| 'repo-ids';
 
+/**
+ * Whether a scope name survives the provider's sanitizing, i.e. whether it will actually constrain the query.
+ *
+ * Provider-NEUTRAL by design, and deliberately not an import of GitHub's `sanitizeGitHubQualifierValue`: this
+ * module validates for every provider, and a GitHub-specific rule reaching in here would be wrong for the next
+ * one that declares a search. What is common to any query language is the part that matters: a value made only of
+ * whitespace, quotes and control characters carries no name, and every sanitizer strips exactly those (quotes
+ * because they would close their own qualifier, control characters because they cannot appear in a query at all).
+ *
+ * Strictly weaker than any provider's own sanitizing, which is the safe direction: this can only pass a name the
+ * provider would then narrow further, never reject one the provider would have accepted.
+ */
+function isUsableSearchScopeName(name: string): boolean {
+	// eslint-disable-next-line no-control-regex
+	return name.replace(/["\u0000-\u001f\u007f\s]/g, '').length > 0;
+}
+
 /**
  * Validates that a filtered issue search is scoped at all, and narrows `repos` to the descriptor form the
  * provider query needs.
@@ -322,6 +353,13 @@ export type IssueSearchScopeRejection =
  *
  * The two rejections are mutually exclusive — `repo-ids` requires repositories and `unscoped` requires none — so
  * the order they're checked in cannot change the outcome.
+ *
+ * An org is checked for what SURVIVES SANITIZING, not merely for being non-empty, and that distinction is a
+ * SECURITY one rather than a nicety: the provider query drops a value that sanitizes away rather than rejecting
+ * it (`toGitHubIssueSearchScopeQualifiers` emits no bare `org:`, which GitHub would reject), so an org of `'   '`
+ * or `'"'` would pass a length check, emit NO scope qualifier at all, and leave a search of the entire host —
+ * measured at 52 million issues across unrelated accounts. Whitespace and quotes are exactly what a name pasted
+ * from a config or a URL degrades to, so this is reachable without anything adversarial.
  */
 export function resolveIssueSearchScope(
 	repos: ProviderReposInput | undefined,
@@ -335,7 +373,7 @@ export function resolveIssueSearchScope(
 		return { repos: repos as ProviderRepoInput[] };
 	}
 
-	if (org != null && org.length > 0) return {};
+	if (org != null && isUsableSearchScopeName(org)) return {};
 	if (criteria?.relationships?.some(r => userScopingIssueSearchRelationships.includes(r)) === true) return {};
 
 	return { rejection: 'unscoped' };