MediumCodingTechnical

A search component keeps the last successful results visible while a newer search is pending. Each request has an increasing request ID. Its success handler checks whether the ID is still active, but its failure and cleanup handlers do not:

1Give yourself 5 minutes

2Answer out loud, not in your head

3Then compare with the answer below

The problem

start(id, query):
  activeId = id
  loading = true
  error = null
  fetch(query)
    .then(result):
      if id == activeId: results = result
    .catch(err):
      error = err.message
    .finally:
      loading = false

Use this controlled schedule. R1 starts for ann and remains pending. R2 starts for anna and succeeds with [Anna Rao]; its cleanup finishes. R3 starts for anne and remains pending. Then R1 rejects with a network error and its cleanup runs. Identify the wrong visible state, specify the correct state at that point, and design a deterministic test and repair. All requests use the same account; authorization and cache-key scope are outside this fixture.

Reference answer

The guarded success path is incomplete because R1's unguarded catch assigns an irrelevant error and its finally clears the loading state owned by active R3. After R1 settles, activeId must remain R3, loading must remain true, and the current error must remain null. Under the supplied display policy, the last successful [Anna Rao] results can remain visible with a clear indication that anne is still loading; they are not a confirmed result for the new query. Guard current-view success, error, and loading transitions by active request identity. Cleanup may still remove R1 from its own pending-operation record and release its resources, but must not overwrite R3's view state.

Use deferred promises or a controllable fake transport. Start R1 and R2, resolve R2 and await its handlers, start R3, reject R1 and await its catch/finally, then assert the exact state above. Finally resolve R3 with [Anne Li] and assert that its result becomes current, its loading flag clears, and no R1 error reappears. The test must observe state after each controlled settlement, rather than rely on timed sleeps. Include the alternate stale-success schedule so all three lifecycle paths remain protected.

Then expect these follow-ups

If R3 also rejects, which error should be shown and when should loading clear?
If the component tracks a pending-request set, which entry may R1 cleanup remove?
Does aborting R1 remove the need for identity guards when rejection or completion races with cancellation?
How would you show retained results without labelling them as matches for the new query?

Free to read · better with Enzo

Practice this out loud with Enzo

Enzo runs it as a mock interview, pushes back with follow-ups, and grades you on the rubric.

Continue with Enzo Sign up free