Why did the older search replace the newer result?
A reader types two searches. The newer request completes first, yet an older completion changes the visible screen.
The question
Fictional exercise. The supplied code, data and outcomes are authored teaching examples, not an employer question or model output.
let generation = 0;
async function search(query) {
const mine = ++generation;
state.query = query;
try {
const items = await request(query);
state.items = items;
state.error = null;
} catch {
state.error = 'Search unavailable';
}
}- StartRequest A starts, then request B starts. state.query is B.
- First completionB succeeds with B's items.
- Later completionA can either succeed with A's items or fail. Both schedules must preserve B's visible state.
Only the latest started request owns visible items and errors. An older success or failure must not change them. The supplied request function is an authored deferred result, not a network call.
“Trace both older-completion paths. Where should ownership be checked?”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: State ownership before timing
What would you do here? Open the move you’d make.
Keep whichever completion happens last
Tempting, but it misses something. That can replace B with older A.
Let the latest started request own visible state
The strong move. This is the explicit contract for both success and failure.
Let the oldest request win
Tempting, but it misses something. That ignores the reader's newer search.
See how a strong candidate says it
“B is the latest started request, so only B may update visible items or errors. Completion order is not the ownership rule.”
Why it works: The required result comes from request identity, not response speed.
Step 2: Find both witnesses
What would you do here? Open the move you’d make.
Trace A success and A failure after B
The strong move. Both callbacks can violate B's ownership.
Test only A then B finishing in order
Tempting, but it misses something. That schedule hides the stale update.
Assume declaring mine is enough
Tempting, but it misses something. The starting code never checks mine before writing.
See how a strong candidate says it
“After B succeeds, A's success overwrites items in the starting code. A's failure instead sets an error on B's successful view. The unused mine value does not protect either write.”
Why it works: A success-only demonstration can miss an old failure's effect.
Step 3: Put the guard at the writes
What would you do here? Open the move you’d make.
Guard only the successful result
Tempting, but it misses something. An old failure can still change B's error state.
Clear all results on every completion
Tempting, but it misses something. That also destroys the latest request's useful result.
Guard both success and failure writes
The strong move. It preserves the latest request's visible state in both supplied schedules.
See how a strong candidate says it
“Before changing state in either completion branch, return if mine !== generation. Cancelling older work may reduce effort, but the contract still needs a guard when an older result settles.”
Why it works: Ownership must be checked where visible state changes.
Step 4: Verify the schedules and limit
What would you do here? Open the move you’d make.
Call cancellation alone a proof
Tempting, but it misses something. The packet does not promise that cancellation prevents settlement.
Check both stale paths and name the boundary
The strong move. The checks address the visible-state contract.
Wait a fixed second before writing
Tempting, but it misses something. A timer does not identify which request owns the result.
See how a strong candidate says it
“Check normal A-then-B completion, B-before-A success, and B-before-A failure. In every case the latest request owns items and errors. These authored schedules do not establish broader network or cancellation behavior.”
Why it works: The repair's evidence should cover the actual competing writes.
The answer, in short
- Decision
- Guard every completion write by the latest request generation.
- Because
- Both an older success and an older failure can replace newer state.
- What would change it
- A different product rule for stale results would change the ownership contract.
Common traps
- Treating a plausible result as proof of the full contract.
- Claiming more than the shown inputs and checks establish.
Check your answer
- Did you distinguish start order from completion order?
- Did you trace both old success and old failure?
- Did the guard protect items and errors?
- Did you avoid claiming live network or cancellation proof?
Last reviewed Nov 10, 2026