The task and original case
Write a bounded request wrapper whose error path is as understandable as its success path. The project uses deterministic response fixtures, with no live requests required. Your goal is a small retry policy that can be explained and tested, not an unlimited promise to recover from every failure.
| Case element | Value or requirement |
|---|---|
| Inputs | Fixture A returns 503 then 200; fixture B returns 404; a third fixture exceeds a declared attempt limit. |
| Build | A bounded request wrapper and an error report, with HTTP failures checked explicitly. |
This is an original invented exercise. It is independent practice, with no employer assessment or open-vacancy claim. Download the inputs, attempt your own result, then open the separate answer key.
Data and worked inputs
Build a result another person can follow
Set a maximum of three total attempts for this exercise. Treat a GET returning 503 as retryable, and a GET returning 404 as a terminal HTTP error. Declare a short bounded delay policy and inject the delay function so tests can record waits without actually sleeping. Treat transport failures separately from HTTP responses.
Fetch does not reject merely because an HTTP response reports an error status; MDN documents checking the response. After each attempt, inspect status before reading a success body. Return successful content on 200, stop immediately on a nonretryable status, and stop after the third attempt on repeated 503. Record attempt count, last status and the final reason. This practice policy is intentionally narrower than a complete production retry strategy.
Sources[1]
Check the worked result
Fixture A returns 503 followed by 200. It succeeds on attempt two and should record one retry delay. Fixture B returns 404, so it fails after one attempt with no retry delay. A third fixture returning 503 every time fails after three total attempts, not three retries after an initial request.
Your report should make the distinction between attempts and retries explicit. An error message that says only “failed” loses the most useful evidence for reviewing whether the policy worked.
Make the failure visible
Test a malformed success body separately from a retryable status. Repeating a request will not necessarily fix a schema mismatch. Also test an already-cancelled request and ensure cancellation does not start more attempts. Do not automatically apply this GET exercise to payments or other write operations: safe repetition depends on the operation's actual semantics.
Revise it and ask someone to reproduce it
Ask a peer to trace each fixture by hand before running it. Change the maximum to two, then verify that the always-503 case stops at two attempts. Keep the attempt log beside the result and revise any wording that led your partner to count “three attempts” as “four requests.”
- 503-then 200 uses two attempts;404 uses one.
- Exhaustion respects the declared total-attempt bound.
- Cancellation, body errors and HTTP errors have distinct outcomes.
Describe the work accurately
After completing your own version, you could adapt this project bullet: “Implemented an independent bounded GET-retry exercise with explicit HTTP checks, terminal errors and inspectable attempt counts.”
Use Projects or Independent practice as the heading. Keep the input files, result and revision together. Describe only your own completed work; the invented numbers are model outputs, not employer results or measured business impact.