Premier League Predictor: FastAPI & Redis — Chapter 10, Exercise 3
==================================================================

TASK
Select gameweeks 1, 2 and 3 in quick succession where the responses take
80, 40 and 10 ms respectively. Report which gameweek a naive handler and
the ticketed loader end up showing, and how many requests were still sent.

SOLUTION

Node test with a stubbed fetch (delay: GW1 80 ms, GW2 40 ms, GW3 10 ms),
three select() calls fired back to back:

  naive handler   (render whatever arrives last):  shows gameweek 1
  ticketed loader (createLoader):                  shows gameweek 3
  requests sent through the loader:                3

The naive handler renders GW3 first (10 ms), then GW2 (40 ms), then GW1
(80 ms), so the slowest and oldest response overwrites the correct one
and the page ends up on gameweek 1 while the menu says gameweek 3.

The loader gives each request a ticket number. When a response arrives
it is rendered only if its ticket is still the latest, so the responses
for GW1 and GW2 are discarded and GW3 stays.

All three requests were still sent and answered: the ticket stops old
answers from being shown, not old requests from being made. To avoid the
wasted work the requests would need to be cancelled (an AbortController
per selection); for two menus in a one-person tool the wasted requests
cost nothing noticeable.

WHY THIS WORKS AS AN ANSWER
----------------------------
It runs both handlers on the same timing, explains the arrival order that
causes the naive result, and is honest that the fix hides stale answers
without cancelling stale requests.