Reviewing AI-assisted code: reproduce the late response first

01 / Make the failure observable

Send query A, then AB. Resolve AB first with [new], and A later with [old]. An implementation that renders every successful response ends with old. The required outcome is that the newest query owns the visible state, regardless of completion order.

The existing fixture exposes resolve and reject functions instead of using random delays. This makes success order, rejection order and disposal repeatable without a server.

02 / Compare three decisions

Debounce reduces how often work starts. It cannot order work that has already started. AbortController asks an adapter to stop; a cache or test adapter may ignore the signal. A sequence ID decides whether a returned result still has permission to render.

The example uses cancellation and a sequence guard together. Clearing the input advances the sequence before returning to idle; dispose also advances it. Guarding only the success branch would still let an old failure replace current loading feedback.

03 / Read the assertions, then run them

The four cases cover a late success that ignores cancellation; stale versus current rejection; clearing and disposal; and empty results. All four passed in this review. They verify the controller, not DOM behavior, HTTP validation or application authorization.

node --test notebook/examples/latest-request.test.mjs

04 / What I take from this exercise

For AI-assisted development, the useful review question is not whether the function looks complete. Ask which event owns the right to change state. A prompt can request explicit states and tests, but passing tests must be checked against the actual failure sequence.

Next, add an adapter that validates HTTP status and payload shape, then check loading announcements and focus in the browser. For writes, canceling a browser request does not roll back a server transaction.