When not to use QueuedTask

ShawnPacararCC

I've been developing an add-in where my main workflow is to subscribe to events in ArcGIS Pro and report a summary of important events to our server which drives a dashboard on a web client. A big goal of our add-in is to be minimally intrusive to the user. That idea alongside the need to sometimes be required to use the MCT, we rely heavily on QueuedTask.

A typical flow in our application is to do something along the lines of this snippet:

GPExecuteToolEvent.Subscribe((evt) => QueuedTask.Run(() => {
  // parseGPEvent may require MCT
  var parsedEvent = Helper.parseGPEvent(evt);
  if (parsedEvent != null) {
    var name = $"tool:{parsedEvent.items[0].title.ToLower()}";
    // the new ArcEvent constructor may require MCT
    this.ReportEvent(new ArcEvent(name, parsedEvent));
  }
}));

I've read some of the documentation like
- https://github.com/Esri/arcgis-pro-sdk/wiki/ProConcepts-Framework#using-queuedtask
- https://www.youtube.com/watch?v=9tQKOMoLa2w
- https://github.com/esri/arcgis-pro-sdk/wiki/ProConcepts-Asynchronous-Programming-in-ArcGIS-Pro#using-queuedtask

These all document why it's good to use QueuedTask and when it's required, but none of them really mention anything to avoid being in a QueuedTask except for user input. I know there are a few caveats how we've wrapped the entire event parsing in a QueuedTask and some variables can change between the subsciption callback and the QueuedTask execution. I may need to do better about mitigating that, but my main concern is if there is anything that should be explicitly avoided from the QueuedTask and what a better solution might be?

I think perhaps our api call (within ReportEvent) might be better suited to a BackgroundTask; however, having the events be sent to our server in the same order they happen on the client is somewhat beneficial and putting them in BackgroundTask sounds like that would no longer be guaranteed. I don't want to block the ui thread so not putting them in any task sounds like it would not be ideal, but I also have read that longer running tasks should avoid blocking the MCT. I've also noticed that because I'm waiting for the MCT certain things like the python window can block our events from being sent until the completion of the python script. This GPExecuteToolEvent in particular can end up being somewhat mis-reported because all the events will queue up while the script is running, then will all fire back to back once the script frees up the MCT.

In general, is there anything besides UI interaction that should NOT be included in a QueuedTask? Do you have any recommendations for this particular workflow or further documentation that might help explain more complex use cases? It seems that most of the add-in examples don't really do a lot of work on their own, but typically will just run Pro SDK commands.