fix(github): classify access, network and server failures; cancel a listing promptly; no progress after a final state #153

New Issue

2026-11-10T21:10:34Z

james.maes commented

2026-11-10 21:10:34 +00:00

Found in the 1.1.1 review.

Failures that are not gclo's fault are reported as a bug in gclo. The listers translate a rejected token (401), rate limits, and "not found". Everything else GitHub or the network can answer with escapes untranslated: a refusal of access (403, for example an organization that enforces SAML single sign-on), an error on GitHub's side (5xx), a network failure, and a request that times out. In the CLI those end as exit code 70, "unexpected error ... please report it"; in the desktop app a timed-out organization lookup is taken for a superseded one and shows nothing.

Expected: one shared mapping, used by both listers.

403 → access refused, exit code 3, with GitHub's own reason in the message.
Network failure, timeout, 5xx → "retry later", exit code 4.

This changes exit codes that scripts may look at (70 → 3 or 4 for these cases), so it goes into the release notes and docs/CLI.md.

A listing cannot be canceled while a request is under way. Cancellation is only looked at between pages, so Ctrl+C during a hung request waits for the HTTP timeout.

Progress can arrive after a repository's final state. A git operation that was abandoned on cancel keeps reporting transfer progress, so a row can go from "Canceled" back to "Cloning NN%", and the CLI can print a progress line after the summary. Once a repository has reported its final state in a run, later progress for it in that run should be dropped.

Found in the 1.1.1 review. **Failures that are not gclo's fault are reported as a bug in gclo.** The listers translate a rejected token (401), rate limits, and "not found". Everything else GitHub or the network can answer with escapes untranslated: a refusal of access (403, for example an organization that enforces SAML single sign-on), an error on GitHub's side (5xx), a network failure, and a request that times out. In the CLI those end as exit code 70, "unexpected error ... please report it"; in the desktop app a timed-out organization lookup is taken for a superseded one and shows nothing. Expected: one shared mapping, used by both listers. - 403 → access refused, exit code 3, with GitHub's own reason in the message. - Network failure, timeout, 5xx → "retry later", exit code 4. This changes exit codes that scripts may look at (70 → 3 or 4 for these cases), so it goes into the release notes and `docs/CLI.md`. **A listing cannot be canceled while a request is under way.** Cancellation is only looked at between pages, so Ctrl+C during a hung request waits for the HTTP timeout. **Progress can arrive after a repository's final state.** A git operation that was abandoned on cancel keeps reporting transfer progress, so a row can go from "Canceled" back to "Cloning NN%", and the CLI can print a progress line after the summary. Once a repository has reported its final state in a run, later progress for it in that run should be dropped.

james.maes referenced this issue from a commit

2026-11-10 21:16:07 +00:00

fix(github): classify access, network and server failures; cancel a listing promptly

james.maes referenced a pull request that will close this issue

2026-11-10 21:16:08 +00:00

fix(github): classify access, network and server failures; cancel a listing promptly #154

james.maes referenced this issue from a commit

2026-11-10 21:38:55 +00:00

fix(github): classify access, network and server failures; cancel a listing promptly

james.maes referenced this issue from a commit

2026-11-10 21:38:55 +00:00

fix(github): address the independent review of the failure mapping