Answers and explanations · Handle remote-shaped data locally

A. Follow every state

Normal data reaches success with cards. An empty array reaches success with an empty-data message. Malformed JSON fails body parsing; wrong-shape JSON fails domain parsing. Both show a recoverable error. Retrying the same bad fixture may honestly produce the same error. Selecting normal data starts a fresh loading attempt and then recovers. A filtered zero-match result has a successful nonempty dataset but no records matching the current controls.

B. Repair a race

Without protection, A-start → B-start → B-success → A-success leaves A visible under B's selection. Cleanup marks A obsolete and aborts its request. Success and failure handlers check whether their effect run is still active before changing state. The intended final UI remains B regardless of A's later completion. Aborting alone should not be treated as the learner's error, and guards protect later promise steps that may already have begun.

C. Transfer

Use controlled promises or the supplied deferred-request test pattern. Start the first load, switch to a second, resolve the second with valid B records, then resolve the first with A records. Await B's visible heading and assert A does not replace it. A second case rejects the old promise after B succeeds. For HTTP failure, return a response with an unsuccessful status; for malformed JSON, return a successful status with invalid body syntax. Avoid timing sleeps. These tests establish the state-ordering contract in the test environment; a real browser must still check fixture URLs, visible loading, retry keyboard use and network behavior.