Overload Retry

GitAuto handles HTTP 529 (overloaded) errors with exponential backoff retry. When the model's API returns an overload response, GitAuto waits progressively longer between retries instead of immediately failing.

Why This Exists

HTTP 529 errors are transient - the model is temporarily busy serving other requests. Retrying after a short wait usually succeeds because the server has processed some of its queue. Without backoff, rapid retries make the problem worse by adding more load to an already overloaded system. A single 529 error should not cause an entire PR generation to fail when waiting 30 seconds would resolve it.

How It Works

When a 529 response is received, GitAuto waits before retrying. The wait time doubles with each retry: first 10 seconds, then 20, then 40, and so on. This exponential backoff gives the server time to recover. After a configurable number of retries (typically 3-5), if the model is still overloaded, GitAuto falls back to the next model in the fallback chain rather than continuing to retry indefinitely.

Other Transient Failures

The same retry mechanism covers transient upstream failures from any provider, not only model overload. HTTP 5xx responses (500, 502, 503, 504) from GitHub, Anthropic, OpenAI, Supabase, or any other API are retried with linear backoff before the call gives up. Connection-level drops (RemoteDisconnected, ChunkedEncodingError) and Google CANCELLED responses are treated the same way. Rate-limit responses (403/429 with a Retry-After hint) honor the server's suggested delay instead of the backoff curve. The retry is bounded so a genuinely down service still surfaces in Sentry instead of looping forever.

Failures that git reports through its own exit status are covered too. Because git writes the reason to stderr rather than returning a response, these are matched on the message: a connection that never opened ("Could not connect to server"), git over HTTPS being rate limited, and an edge node serving a certificate for the wrong name. Each of these clears on the next attempt, so without the retry a whole run would be discarded because one TCP connection timed out.

Failures That Are Not Retried

Retrying only helps when the condition can change. Some responses describe your setup rather than a fault, and no number of attempts will clear them, so GitAuto stops immediately instead of retrying and does not treat them as defects.

• An issue with more than 2500 comments, where GitHub disables commenting outright.
• An installation still on an older permission set, which answers "Resource not accessible by integration" until the owner accepts the updated permissions.
• An installation that has been suspended, or removed from the account.
• A page the agent looked for that does not exist. The agent is told it returned 404 so it can choose a different source, rather than being handed nothing.

Related Features

• Model Fallback - switches to a different model after retries are exhausted