Handle GitHub API rate limits and transient failures

[devblac]

Handle GitHub API rate limits and transient failures

Context

While running prw run against a handful of busy repos, the watcher bailed out as soon as GitHub throttled me. I had to restart the command a few times in the same hour.
 

Repro

• Run prw run on a repo with frequent PR activity for ~10–20 minutes
• Eventually hit GitHub throttling or a timeout; watcher exits instead of retrying

Problem

internal/github/client.go surfaces 403/429 rate-limit responses and network timeouts as hard failures with no retry. The watcher stops polling entirely instead of waiting and trying again.
 

Expected behavior

On transient rate limits or timeouts, the client should back off briefly (respect Retry-After when present) and retry a few times before giving up, with a clear log line about each retry.
 

Scope / non-goals

• Don’t add heavy retry libraries or global jitter configs.
• Keep retries bounded and logging minimal (no log spam).
• Leave unrelated client behavior untouched.
   

Acceptance criteria

• 429/403 responses trigger a limited retry that honors Retry-After headers; missing headers use a short exponential backoff with jitter.
• Network timeouts retry a few times, then return a clear, final error.
• Both GetPullRequest and GetCombinedStatus share the retry logic.
• Watcher logs a concise message per retry attempt.
• Unit tests cover 429/403 with and without Retry-After, plus timeout retries.
   

Hints

internal/github/client.go is the client; add a small retry helper and reuse it.