CLI: Avoid repeated failed region discovery during pagination

Open
  • Is something wrong?
#2,111 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
57/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
node.js, typescript
Domain
backend-api-design, cli

Research direction

Read packages/cli/src/lib/api/projects.ts around listProjects() and packages/cli/src/lib/api/infrastructure.ts around resolveOrgBaseUrl(); inspect the corresponding pagination logic in listMonitors(). Reproduce the 403 discovery response followed by two successful project pages using the fixture HTTP responses and temporary SQLite/cache state described in the issue. Done when the operation makes three requests, returns both pages with unchanged cursors, and preserves the listed cache, retry, account, and authentication behaviors.

Written by the indexing model from the issue text.

Description

bug CLI performance

Follow-up to #1979 (merged November 7). Reproduced on main at 6aa29057e5b307679c33ac885d42895a51868943 with published @sentry/[email protected].

Reproduction

With a stored account and no cached region, call listProjects("example-org"). Return 403 for organization discovery, then two successful project pages connected by a Link cursor:

GET /api/0/organizations/example-org/                   -> 403
GET /api/0/organizations/example-org/projects/          -> page 1
GET /api/0/organizations/example-org/                   -> 403 (repeated)
GET /api/0/organizations/example-org/projects/?cursor=…  -> page 2

Before #1979: 1 discovery + 2 pages = 3 requests. Current main: 2 discoveries + 2 pages = 4 requests, with identical returned projects. For N successful pages under this failure condition, the count changes from N + 1 to 2N.

Cause and scope

listProjects() shares its config, but resolveOrgBaseUrl() now invokes region resolution for every page. Failed discovery returns a non-cacheable fallback, so the next page repeats discovery. Previously this operation resolved once before pagination. listMonitors() has the same structure; not every pagination helper acquired this behavior in #1979.

Acceptance criteria
  • Retain the resolved destination/fallback for the logical pagination operation: the reproduction makes 3 requests and returns both pages with unchanged cursors.
  • Preserve successful discovery, existing warm caches, explicit host/account selection, and authentication-error behavior.
  • A later independent operation can retry failed discovery; isolate decisions by organization, credentials, and deployment.
  • Fix in the CLI using the existing resolver/cache infrastructure. Do not persist failed discovery indefinitely or introduce a second SDK locality cache.

Validation used unmodified CLI modules, real temporary SQLite/cache state and fixture HTTP responses; no production traffic or latency measurements. This can ship as an independent CLI fix before SDK metadata-routing adoption.

Dominant language
TypeScript
Stars
961
Forks
179
Avg merge
15h 33m
Merged PRs (30d)
476

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from getsentry/toolkit

All issues in getsentry/toolkit

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.