Maybe spinners like these need a kind of "dead man's switch", where something needs to keep telling them "yep, still working" every so often, otherwise an error is shown?
Which is a sane pattern if a language has proper destructors (a seemingly non-existent thing in GC-enabled languages, unfortunately).
In C++, you'd stack-allocate an object representing a spinner, that spawns said spinner in its constructor, and deletes it in its destructor. Then the spinner doesn't outlive the processing code, no matter what path execution took to end the processing.
There are similar patterns in GC-enabled languages ("with" idiom). Async does throw a wrench into this a bit, though.
That’s a different pattern than I was trying to illustrate. I was demonstrating unsafely catching/ignoring/hiding errors and asserting health when it’s demonstrably not true
Getting something like a callback for progress would require modifications all the way down the stack, akin to what's needed for fully async code.