The task and original case
Reproduce a search race in which an older request finishes last, then prevent it from replacing the newer answer. The useful portfolio evidence is the completion timeline and final rendered result. A fast happy-path demo cannot establish that the race has been handled.
| Case element | Value or requirement |
|---|---|
| Inputs | Request A starts first but finishes after newer request B. |
| Build | A race-condition reproducer, correction and final-render assertion. |
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
Create two controlled request promises rather than relying on network speed. Start request A, then start B. Resolve B first with its result, then resolve A. In the broken version, both callbacks update the same result state, so A's late response overwrites B.
Assign each new request a monotonically increasing identity. Capture that identity when the request starts; before committing either success or error state, compare it with the current identity. Only the current request may update the view. MDN documents AbortController with Fetch; cancellation can reduce obsolete work, while the identity check explicitly prevents obsolete completion from committing. Apply the guard to loading and error updates too.
Sources[1]
Check the worked result
After B resolves, the visible result is B. After A subsequently resolves, it must still be B. Your test should assert the final rendered content after both completions, rather than merely checking that B appeared briefly.
Repeat with A rejecting after B succeeds. A's stale error must not replace the current successful result. This second case demonstrates why guarding only the successful response is incomplete.
Make the failure visible
Create A and B with the same query string but separate identities. The later request should still own the view; comparing query text alone cannot distinguish a refresh from an earlier request. Also test B failing while A later succeeds: the final view should show B's current failure under the declared rule, not silently restore A's older answer.
Revise it and ask someone to reproduce it
Give a peer the controllable fixture and ask them to choose the completion order. Record the sequence that broke the old version, then show the corrected final assertion. For a second revision, add a third request C and verify that every completion order leaves only C eligible to update the result.
- The failing completion order is reproducible without real-network timing.
- Late success and late error cannot overwrite the current request.
- Final rendered output is checked after all fixture promises finish.
Describe the work accurately
After completing your own version, you could adapt this project bullet: “Built and corrected a fixture-driven stale-response race; verified that only the latest request can commit success, error or loading state.”
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.