Transient 502s: retry idempotent reads, distinguish rate limits, expose sending limits

Abierto
  • ¿Algo no está bien?
#521 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
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
42/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
api, cli

Línea de trabajo

Start by tracing how the CLI handles errors for box, search, thread read, and draft show, then compare that with compose and auth status --json. Define the retry, rate-limit, server-error, Retry-After, and sending-limit behavior, including --no-retry and hey limits; done means these cases are distinguishable and documented without automatic compose retries.

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

Descripción

Context

During bursts of CLI calls, read endpoints return API error: 502 Bad Gateway for a while, then recover on their own: hey box imbox, hey search, hey thread read. The same happens to compose. In the case we saw, reads recovered within minutes while compose kept failing much longer.

From the CLI there is no way to tell whether this is rate limiting, a quota on outbound mail, or a server problem. Every failure is the same generic api error.

No account-specific details below.

Ask

  • Retry idempotent reads (box, search, thread read, draft show) automatically with backoff, a few times, before returning an error. A --no-retry flag can turn it off.
  • Map responses to distinct error codes: 429 as rate_limited, 5xx as server_error. Include Retry-After in the JSON when the server sends it.
  • Document or expose sending limits (messages per hour or day, recipients per message) so batch tools can pace themselves instead of discovering a limit through errors. Something like hey limits, or fields in hey auth status --json, would do.
  • Don't retry compose automatically (see the companion issue on compose 502s after a successful send). For compose, report the outcome clearly instead.

Why it matters

Agent and script workflows (reply checks, follow-ups, stop watchers) run unattended. Transient read errors turn into missed replies or false "no thread" results, and silent limits turn into partial batches.

Lenguaje dominante
Go
Estrellas
420
Forks
54
Merge medio
1 d 3 h
PR fusionados (30 d)
43

Preparar el entorno

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 basecamp/hey-cli

Todos los issues de basecamp/hey-cli

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.