Refine Pro Geoprocessing process to allow for rapid and graceful cancellation of running tasks

[RTPL_AU]

Redesign the Geoprocessing execution workflow to make the "Cancel" button work.

If I realise a parameter is wrong for an expected-to-run-a-while geoprocessing task the "Cancel" button fails to stop the task gracefully. The only option is to force close Pro and start from scratch. 

Please recode the process to allow the cancellation to first pause ALL related processes, then inform the user of locks and implications, then provide a few options such as kill all, stop and wait, continue, release all locks, etc.

This is not a support case hidden as an idea but request for functionality to improve the efficiency of Pro.

[RTPL_AU]

Example:
I start a batch geoprocessing task to clip & import 50 tifs to an FGDB. As soon as I click 'Run' I realise I forgot to specify the output coordsys and the rasters do not have one embedded.  
Click Cancel and it will hang at Cancelling until you force close Pro from Task Manager. 
It has been like this from Pro 1.

[BBicking1]

Hello RTPL_AU,

which version of ArcGIS Pro are you working with?

I'm asking because in the just released 3.3 we, Geoprocessing, have improved the performance of cancel. If possible, consider migrating to 3.3.

[BBicking1]

You can read up on it here in What's New in ArcGIS Pro 3.3
https://pro.arcgis.com/en/pro-app/latest/get-started/whats-new-in-arcgis-pro.htm#ESRI_SECTION1_463DC...

[RTPL_AU]

@BBicking1   I don't see it specifically mentioned in the "What's New".  I did read through it before making the Idea post.

Just tested and seems to work better than 3.2.2 on a test PC.

This goes to some of my other posts that Esri needs to start documenting things better, make said docs more discoverable, and thereby not waste paying customers' time.

[BBicking1]

@RTPL_AU, you are right, it isn't specifically mentioned.

The performance improvements made in the GP Framework in 3.3 include cancel.

Thanks for reporting that you see the evidence.

[MargaretCrawford]

Tool cancellation was not updated in Pro 3.3.
But we are currently working on some new approaches to it.
Right now, tool cancelation is done at the tool level. The reason you may see faster cancellation could depend on the tool you are using, or a variety of other factors. These comments do a good job at explaining everything: https://community.esri.com/t5/arcgis-pro-questions/why-is-arcgis-pro-so-slow-to-cancel-a-simple/m-p/... 

The framework changes made in Pro 3.3 speed up repetitive process, so you may also see some performance improvements there. 
https://community.esri.com/t5/arcgis-pro-questions/new-workspace-caching-in-pro-3-3-improved-gp/m-p/... 

[BBicking1]

Hello @RTPL_AU,

before this all gets more confusing, I'd like to clarify "The performance improvements made in the GP Framework in 3.3 include cancel." from my last post. 

Performance of 'Cancel' in and by itself was not worked on in 3.3.

Cancellation is highly individual to each tool. Because of the individual nature of how tool developers implemented cancellation in each tool, it is possible and likely to see/experience cancellation improvements in 3.3, and also before, coming from the performance improvements made in the GP Framework. Improvements made there show in tool execution being faster and with it the responsiveness of the tool returning to you is faster. And that can and does include when a tool is canceled.
2 simple Example:

• A tool has 6 items to process. Each item takes 5 seconds. Tool cancellation checks after each item. When the user cancels the tool execution, the tool returns after 5 seconds.
• A tool has 100 items to process. Each item takes 5 seconds. A cancellation check is done after every 20 items. When the user cancels the tool execution, the tool returns after 100 seconds. 

Library calls or calls out to a website impact the tool's execution, completion, and, if canceled, the response time to be available to you again.

Per developer, performance improvements for cancel in 3.4 are in the discussion phase.


If you have not already, @RTPL_AU, strongly consider using Python for your batch clipping of this number of rasters.

[RTPL_AU]

@BBicking1  Interesting on the input count and cancellation delay. 

Not everything has to be a script 🙂    Cancelling a running Notebook process is another bear in the woods.

If there are limitations to tools they should be made clear in the tool description or even a hint at the input data field e.g. "This tool may crash or be difficult to cancel with this number of inputs. Please consider using a script or reduce the number of inputs"
Only Esri will know the limitation for each tool so it shouldn't be up to paying customers to figure out the limit of each tool be it 2, 10, 100.
With serious hardware and 2024 I did not think a 50 input rasters are a problem for a 64bit multithreaded app by the world leader in GIS.... Happy to be wrong.

I'll wait for future versions to have this resolved and operating efficiently.