CLI: Avoid repeated failed region discovery during pagination

Ouverte
  • Quelque chose ne va pas ?
#2,111 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
1-2 jours
Accessibilité débutants
57/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
node.js, typescript
Domaine
backend-api-design, cli

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

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.

Langage dominant
TypeScript
Étoiles
961
Forks
179
Merge moyen
15 h 33 min
PR mergées (30 j)
476

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de getsentry/toolkit

Toutes les issues de getsentry/toolkit

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.