CLI: Avoid repeated failed region discovery during pagination

Offen
  • Stimmt etwas nicht?
#2,111 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
57/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
node.js, typescript
Bereich
backend-api-design, cli

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
TypeScript
Sterne
961
Forks
179
Ø Merge
15 Std. 33 Min.
Gemergte PRs (30 T.)
476

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus getsentry/toolkit

Alle Issues in getsentry/toolkit

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.