Cancelling a script run takes too long to regain control of QuPath

[yau-lim]

As a follow up to the image.sc thread (https://forum.image.sc/t/feature-suggestion-option-to-revert-to-last-state-on-cancelling-script-run/74486), there could be a quicker way to cancel a running script and regain control of QuPath.

Currently, on cancelling a script, QuPath will continue to run the current script until completion for the current image. For complex scripts, this can take a long time, from minutes to hours.

I would imagine that for most users, when they cancel a running script, they would expect it to halt immediately and regain control of QuPath. Example scenarios for this would be:

• The user quickly notices some errors or mistakes in the script just after running it and would like to correct it.
• The script is running for an unusually long time and the user would like to investigate why (e.g. too many objects created or manipulating extremely complex ROIs?).

At the time of writing, I and other users would just close QuPath or kill its instance and re-open the project to "cancel" the script run. It is unclear if this may cause data corruption or any other negative consequences. One small inconvenience for this method is that any unsaved scripts in the Script Editor will be lost, which can be the case when testing or optimising parameters.

I have suggested in the image.sc thread if there is a way to revert to the last state just before running the script when trying to cancel the script run. From my naive perspective, it could be like:

For scripts running on the currently open image only, on clicking Run,

1. Save current state of image before running the script.
2. Start running the script.
3. If run is cancelled, load the state saved in step 1.

For scripts running in batch, on clicking Run for project,

1. Start running script as usual.
2. If run is cancelled, ignore whatever that has been done on the current image being processed and maintain the last saved image data. Any images that had already completed processing the script would have an updated and saved image data (as per normal behaviour).

[yau-lim]

Small update on this issue for QuPath v0.4.3. I previously mentioned

It is unclear if this may cause data corruption or any other negative consequences.

after closing QuPath to cancel a running script.

However, this action now causes a corruption of the .qpdata file for the project entry that the script is currently running on. This corruption results in QuPath being unable to read the hierarchy data for the project entry. See https://forum.image.sc/t/hierarchy-is-null-cannot-invoke-can-anyone-help/78488/10 for details.

[petebankhead]

this action now causes a corruption of the .qpdata file

I'm not sure anything relevant in QuPath has changed - could it rather be that sometimes data is corrupted if the force quit happens at exactly the time the file was being written, but not otherwise?

If so, it probably wouldn't be new behavior, but it also wouldn't happen consistently (and generally only with larger files that take longer to write).

[yau-lim]

If so, it probably wouldn't be new behavior, but it also wouldn't happen consistently (and generally only with larger files that take longer to write).

You are right about this. The corruption did occur on a very large file (the qpdata file is 500 MB), and it is likely that I force quit when QuPath was writing to it.

I just wanted to mention that the corruption can certainly occur now as I was previously unsure.