Requests can finish in a different order from the order they started. A slow response for an older selection can arrive after a faster response for the user's current choice. If both responses write state unconditionally, the screen shows the wrong route even though each request succeeded.
You'll reproduce that race with two deterministic local delays. Select the older route, then select the newer route before the first result arrives. The newer result must remain visible after both timers finish. Tie each effect run to its own cleanup, either by invalidating the old result or canceling the scheduled work. The fixture changes the route labels and the slow delay, so the correct answer must follow selection order rather than a hardcoded label.
function App(){const [request,setRequest]=useState(null),[route,setRoute]=useState('None');useEffect(()=>{if(!request)return;let current=true;const timer=setTimeout(()=>{if(current)setRoute(request.value)},request.delay);return ()=>{current=false;clearTimeout(timer)}},[request]);return <><h1>{f.organization}</h1><button onClick={()=>setRequest({value:f.primary,delay:f.delay})}>Older route</button><button onClick={()=>setRequest({value:f.secondary,delay:10})}>Newer route</button><output aria-label="Route">{route}</output></>}
Trace the state change and its visible boundary before building the transfer tasks.