How can I keep one failed request from leaving a loading indicator stuck?

Put the reset in a finally block rather than only after the success path. A promise’s finally() callback runs after it settles, whether it fulfills or rejects, making it suitable for cleanup such as resetting a loading indicator [S1].

For example, in a React-style component:

async function loadItems() {
  setLoading(true);
  setError(null);

  try {
    const items = await fetchItems();
    setItems(items);
  } catch (error) {
    setError("Could not load items. Please try again.");
  } finally {
    setLoading(false);
  }
}

The catch handles the failed attempt; finally clears the loading state after either outcome. Adapt the setters and error message to your app. This pattern does not establish why a particular request failed or guarantee that it will succeed.

You can reset it in both the success and failure paths, but that duplicates cleanup and makes it easier to miss a path later. finally puts the shared reset in one place. Keep it focused on cleanup: if the request rejects, handle that rejection in catch or pass it to a caller that handles it. A throw or rejected promise inside finally can change the final outcome, so avoid putting unrelated error-prone work there [S1].

A useful separation is: try for the request and success updates, catch for error handling, and finally for ending this attempt’s loading state.

Usually, represent two different facts with separate state: whether a request is currently in progress, and whether the user can retry. Once an attempt has failed, set loading to false and show an error and retry button. When the user starts another attempt, set loading to true again. Keeping a spinner active while no request is running can make the page appear stuck rather than ready for a retry.

After the failure in the example, render the retry control when there is an error and loading is false. Its click handler can call loadItems() again. Whether to retain old results, clear them, or show a different message is an application-specific design choice; promise cleanup does not prescribe that behavior [S1].

First, confirm that every path which turns loading on reaches the try and its finally. Put the request call inside the try, as in the example, so a synchronous throw from that call also reaches the cleanup. Next, check that the indicator reads the same loading state you reset, and that no later code sets it back to true. If your framework batches updates or the component can be removed during the request, inspect that behavior separately; the promise cleanup reference does not establish how your interface handles those cases.

Use this quick review checklist:

1. Set loading to true when an attempt starts.
2. Put the awaited request inside try.
3. Handle or deliberately propagate failure in catch.
4. Reset loading in finally.
5. Show retry as a separate action, not as a permanently active loading state.