Transient 502s: retry idempotent reads, distinguish rate limits, expose sending limits
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 42/100
Research direction
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.
Written by the indexing model from the issue text.
Description
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-retryflag can turn it off. - Map responses to distinct error codes: 429 as
rate_limited, 5xx asserver_error. IncludeRetry-Afterin 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 inhey 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.
- Dominant language
- Go
- Stars
- 409
- Forks
- 49
- Avg merge
- 23h 49m
- Merged PRs (30d)
- 70
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from basecamp/hey-cli
-
TUI Calendar: Enter does nothing on a highlighted event (Day/Week), though the help bar shows "enter: open"Possibly taken @albertreig claimed this 32 days ago. OpenCLI Only
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
CLI Only
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
basecamp/hey-cli#408 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 42/100
basecamp/hey-cli#556 · 1 reaction ·
Maintainers usually reply within 1 day
All issues in basecamp/hey-cli
Similar issues
-
bug go
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
genkit-ai/genkit#6761 · 1 comment ·
Maintainers usually reply within 2 days
-
ready
Difficulty 2/5 1-3 hours Newbie friendliness 92/100
kubeflow/pipelines#14784 · 1 comment ·
Maintainers usually reply within 2 days
-
bug frontend good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
trust: update-propagation-directive requires developer mode while add and remove do notPossibly taken @bhuvan-somisetty claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 2 days
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
oalders/clodhopper#133 ·