Fix the backoff schedule in an HTTP retry helper
Your task
An agent wrote a retry helper for flaky HTTP calls, and its first version crashed instead of retrying. To test the retry policy without real sleeps, the team now plans the delays up front from the status code each attempt gets.
An assistant wrote plan_retry_delays(status_codes, max_attempts, base_ms). It is in the editor. It has a bug. Find it and fix it.
Input and output:
status_codes: the HTTP status code each attempt gets, in order. A code is 0 when the call could not connect or timed out. Otherwise it is from 100 to 599.max_attempts: the most attempts allowed. It can be 0 or negative.base_ms: the first delay in milliseconds, 0 or more.- Return the delays the helper sleeps, in milliseconds, in order, as a list of integers.
Rules the tests check:
- Attempts are numbered from 0 and run in order, at most
max_attemptsof them. Attempt k gets entry k ofstatus_codes. When the list has no entry k, the attempt gets 500: the server is still failing. - A code from 200 to 399, both included, means the call completed. Stop.
- A code of 0, 429, or 500 and above is a temporary failure, worth another attempt.
- Any other code, such as 404, 401 or 100, is a permanent failure. Stop without sleeping.
- After a temporary failure on the last allowed attempt, stop without sleeping. No attempt follows it.
- After any other temporary failure, sleep, then make the next attempt. The first sleep is
base_ms, and each sleep after it is twice the one before. - When
max_attemptsis 0 or less, return an empty list.
Examples
plan_retry_delays(status_codes: list[int], max_attempts: int, base_ms: int) -> list[int]Example 1
Input
plan_retry_delays([500, 500, 200], 3, 100)Output
[100, 200]Example 2
Input
plan_retry_delays([404], 3, 100)Output
[]Example 3
Input
plan_retry_delays([0, 429, 200], 4, 50)Output
[50, 100]