Skip to content

core-gitlens: per-connection support for paginated/providersApi reads + read-API parity for Kepler (follow-up to #5430) #5435

Description

@julianmesa-gitkraken

Summary

Follow-up to #5430 (multi-account per provider integration). #5430 added multi-account connection management (stable tokenId/primary, setPrimaryConnection/deleteConnection/refreshConnections, per-connection secret storage) and per-connection reads for the session-based read methods (searchMyIssues, searchMyPullRequests, searchPullRequests, and the IssuesIntegration resource/project reads) via an optional connectionId argument.

Two categories of read still cannot target a specific connection, and there are structural read-API parity gaps that block Kepler (gitkraken/kepler#1325, part of gitkraken/kepler#1322) from migrating its provider reads off the gk CLI onto @gitkraken/core-gitlens.

1. Make the providersApi layer connection-aware (primary ask)

GitHostIntegration.getMyIssuesForRepos and getMyPullRequestsForRepos do NOT flow a session; they call this.getProvidersApi() and pass { providerId }, so the API resolves the token internally via getProviderTokengetSession → the provider primary. They cannot be scoped to a specific connection today.

To close this:

  • Thread an optional connectionId through ProvidersApi read methods (the TokenOptInfo/getProviderToken path) so a specific connection's token is resolved (getSession({ ...descriptor, connectionId })), instead of always the primary.
  • Add the optional connectionId argument to getMyIssuesForRepos / getMyPullRequestsForRepos (and any other providersApi-backed reads that should be per-connection), mirroring the connectionId already added to the session-based read methods in Support multiple simultaneous connections (multi-account) per provider integration #5430.

This matches the gk CLI, which scopes issue list / pr list with --connection <tokenId> and resolves the token via GET /v1/provider-tokens/tokens/{tokenId} (identity-service).

2. Read-API parity for Kepler's ProviderBackend (broader gap found during #5430)

Even with connectionId, core-gitlens's read methods don't fully satisfy Kepler's ProviderBackend read verbs (listIssuesPage, listIssuesForProviders, broadenIssues, listPullRequestsPage, listPullRequestsForProviders, sweepPullRequests, sweepClosedPullRequests). Gaps:

  • Pagination model mismatch. searchMy* return all results (no paging); getMy*ForRepos return cursor-based PagedResult. Kepler expects page-number pagination ({ currentPage, itemsPerPage } + hasMore). Need a page-number-capable read surface (or a documented mapping).
  • Closed/terminal PRs. No open/closed selector on searchMyPullRequests (needed for sweepClosedPullRequests).
  • Assignee/reviewer toggles. No includeAllAssignees (issues) or reviewer-inclusion (PRs) parameters; needed for broadenIssues and the "all visible" issue path.
  • Org/project scoping. searchMy* scope by repo ResourceDescriptor[], not org-wide or Jira/Azure project scoping that Kepler's ProviderScopeFilter needs.
  • PR head/base + fork + clone URLs. PullRequest.refs carries base/head branch + isCrossRepository, but there are no clone URL fields (cloneHttps/cloneSsh) that Kepler's PrHeadRepo/baseRepoClone* expect.

These can be addressed incrementally; the Kepler adapter can do DTO re-shaping/warning-aggregation, but the pagination model, closed selector, assignee/reviewer toggles, and org/project scoping need first-class support (or an explicit "not supported" contract) on the core-gitlens read API.

Acceptance

  • getMyIssuesForRepos/getMyPullRequestsForRepos (and the providersApi read path) accept and honor an optional connectionId, reading with that connection's token; omitting it preserves current primary behavior.
  • A documented decision (support vs. explicitly-unsupported) for each read-API parity gap above, so Kepler Associate vscode-gitlens#1135 with microsoft/vscode#37947 #1325 can migrate reads with fidelity.

References

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions