A stale response can quietly break a recommendation tool

A recommendation page can perform the correct calculation and still show the wrong result. The failure happens when two valid requests finish in the wrong order. Consider a player who starts a Members search, then switches to F2P while the first request is still running. The F2P request finishes quickly and the page shows F2P methods. A moment later, the slower Members response arrives. If the interface accepts it, Members-only methods replace the correct result even though the form still says F2P. Nothing crashed. The API returned valid data twice. The screen became untrustworthy because an older answer won the race.

Give every request an identity

The finder on OSRS Money Maker keeps a counter for recommendation requests. Starting a search increments the counter and stores the new value locally:

const requestId = ++activeRecommendRequest.current

When the response returns, the handler compares its local ID with the current counter:

if (requestId !== activeRecommendRequest.current) return setResults(response)

Changing a setting also increments the counter and clears the old result. Any response created before that change becomes stale immediately, even if the network request cannot be cancelled.

Player lookup needs the same protection

The page can load public Hiscores before it asks for recommendations. That adds another race. A player might type one username, start a lookup, then correct the name before the first lookup finishes. The same request-ID pattern protects this path. Only the latest player lookup may update the stored profile or clear the loading state. The recommendation request also checks whether it is still current after waiting for Hiscores. This prevents a corrected username from being paired with the previous account's levels.

Loading state can become stale too

Race protection has to cover more than the final data. An old request should not:

• clear the spinner for a newer request.
• display an old error after a successful retry.
• scroll the page to results that no longer match the selected settings.

The current-ID check belongs around every state change that depends on the request. That includes results, error messages, loading flags, and follow-up UI actions.

AbortController can save bandwidth

AbortController can save bandwidth when the API supports cancellation. The identity check still earns its place. Cancellation can arrive too late, and some intermediate work may already have completed. A small monotonic counter gives the interface a clear rule about which answer owns the screen. The calculation can be perfectly accurate for the request it received. The product also has to prove that the response still belongs to the choices visible now.