move long-running operations off of the UI thread

[jamesmanning]

NOTE: only creating this issue since I see it mentioned as something needed long-term in other issues but all of them are closed AFAICT. This isn't something that's an easy fix by any means, but as I was hoping to maybe take a shot at this, I wanted to file this both as a place to keep notes and also to try to contribute help from any others that either have already started on this or tried and have valuable insights to share, or even @paolosalvatori just deciding whether he's ok with the idea or not

The proposed 'phases' would be:

Phase 1 - entire UI is still blocked, user can't cancel the operation, but there's a new modal dialog with an indeterminate progress bar that's just cycling and states that an operation is in progress. Bonus points for accepting a specific name for the operation

Phase 2 - entire UI is still blocked by modal, but the modal now includes a cancel button. Implementation should use async/await and CancellationTokenSource / CancellationToken

Phase 3 - progress bars (where possible) implement actual progress

Phase 4 (maybe, distant future) stop blocking the full UI, potentially allow multiple concurrent operations.

[ErikMogensen]

There has been some requests for a progress bar so this is something that will be appreciated if done properly, which is not easy.

Today, I would say that many operations are not blocking the UI thread. However, I have the feeling that all paths does not work properly when another operation is going on.

[jamesmanning]

The operations that block the UI thread (at least AFAICT / IME) are peek and receive+delete on queues/subscriptions. Admittedly, I may be an outlier when it comes to those, but as an example, I used it to drain 1.4M messages from a deadletter queue this past week and it took well over an hour and by all indications was blocking the UI thread the entire time (app won't paint, task manager shows it as not responding, etc).

There are probably tons of operations that either don't happen on the UI thread or do and just run quickly enough that I can't perceive that they're blocking the UI, it's really just those receive/peek operations that are problematic. :)

[SeanFeldman]

I used it to drain 1.4M messages from a deadletter queue this past week and it took well over an hour

Reading this thread, I can't shake off the fact that what SBE is doing is a workaround, to compensate for the missing feature, celebrating its 7th anniversary this month.

[jamesmanning]

@SeanFeldman agreed, although in this case, I needed to download the contents of the 1.4M messages, so a purge operation that didn't grab the message contents wouldn't have helped me in this particular case.

[Dorus]

I'd like to add here that the service bus explorer often hangs (until the timeout) when connection fails. Something that often happens with me switching between different VPN. It would make more sense if the UI kept responsive, and no longer relevant request would be cancelled.