Comment 2 for bug 2057690

To clarify, currently the front-end uses two pieces of information to determine whether an import (and cancellation) is running or not:

- The `downloading` boolean on each individual boot resource
- The result of the `boot_resource.stop_import` WebSocket call

As far as I'm aware, there isn't a definitive way to determine if a cancellation operation is already in progress. What we should really do is persistently track the state of a cancellation operation on the backend, and surface that state to the UI via WebSocket so that it survives page refreshes. E.g. Something like `cancellation_in_progress` or similar returned as part of the boot resources poll message.

What I also noticed is, we do not use the `region_import_running` or `rack_import_running` booleans that are returned by the API. Do you happen to know how these "import running" flags behave when a stop is requested? Are they updated right away, or only once the workflow was actually cancelled (which, as you said, could take 15+ minutes)?

Assuming that's the case, as a temporary solution, we could optimistically update UI to "import stopped" state as soon as a user clicks on the button and stop request is sent, even before any results are returned. This will allow users to continue interacting with the part of the UI that's blocked (Update resources button). But this will only work if resource updates considered a valid operation in case cancellation is still in progress, which I'm not sure of.