Classify an Error as Retryable

1. Background Knowledge

In distributed systems and API interactions, HTTP status codes communicate the outcome of a request. Codes in the 2xx range indicate success, 3xx indicate redirection, 4xx indicate client-side errors, and 5xx indicate server-side errors. Understanding these categories is fundamental to building resilient software.

Transient failures are temporary issues that may resolve themselves if the operation is repeated. Examples include network timeouts, server overload (503 Service Unavailable), or rate limiting (429 Too Many Requests). Permanent failures, such as 404 Not Found or 401 Unauthorized, will not succeed on retry because the underlying condition (missing resource, bad credentials) remains unchanged.

In reliability engineering, a common pattern is to distinguish between these two failure types. Retrying a permanent error wastes resources and can mask bugs, while failing to retry a transient error reduces system availability. This problem models that decision logic: you must classify a status code to determine if a retry is appropriate.

2. Algorithm Approach

This is a simple conditional classification problem. The logic involves checking the input integer against specific ranges and exact values.

The decision tree is:

1. Is the status exactly 429? If yes, it is retryable.
2. Is the status in the range [500, 599]? If yes, it is retryable.
3. Otherwise, it is not retryable.

You can implement this using standard boolean logic (and, or) or a series of if statements. Since the conditions are mutually exclusive in terms of the final boolean result (i.e., you just need to know if any retryable condition is met), a single compound boolean expression is often the most Pythonic and concise approach.

3. Step-by-Step Strategy