CLI: Avoid repeated failed region discovery during pagination

Abierto
  • ¿Algo no está bien?
#2,111 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
1-2 días
Aptitud para principiantes
57/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
backend-api-design, cli

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
961
Forks
179
Merge medio
15 h 33 min
PR fusionados (30 d)
476

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de getsentry/toolkit

Todos los issues de getsentry/toolkit

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.