Add method to cancel renditions

Add method to cancel any application.createRenditions() call.

Use Case:
Trobi has a plugin that creates image previews but sometimes they take a while to create them all. He wants to create a new set of previews but he keeps encountering the error:

Error: Multiple createRenditions() calls cannot run concurrently. Wait for the previous call’s Promise to resolve before calling again.

He wants to cancel the current create renditions call. He uses the new application.cancelRenditions() to cancel any running renditions so he can create new image previews.

How about Trobi just writes bug-free code and doesn’t call createRenditions concurrently? :wink:

1 Like

Trobi would check to see if create renditions was running if there was a flag for when it was running.

In many environments native processes have a process.running flag that developers can check.

In many environments native processes have a cancel method that developers can call.

Not being able to cancel a process is actually a plugin rejection reason. Trobi has had plugins rejected for lack of cancel option.

Trobi is not asking for much.

Trobi decides to get clever, and adds a .then() clause to his createRenditions call, with code to set a global noting that the rendition is done, or to start the next rendition, etc.

Or, he uses await on each rendition so there are never more than one in process at a time…

And, if he has a bunch of renditions to make, he sets up a queue, running through it with the techniques suggested above, and allowing cancellation from his UI at any individual rendition completion, so his plugin will be acceptable.

For now, the best bet is probably to split your renditions calls into small batches that you run sequentially. Then, if the user has pressed Cancel in your progress dialog, you can wait for the current batch to end and then cut off the remaining sequence.

If you’re worried about the user re-invoking your command again too quickly, you could make a simple queue to manage all the requests you’re sending. So if a previous request is still wrapping up and your plugin wants to request more renditions, rather than calling the renditions API and failing your new request just goes onto your queue and it gets run as soon as the previous (currently running) request’s promise finishes.

I thought about breaking it up before but I don’t know what is going on behind the scenes. I am concerned about memory creating new instances for every file or thrashing the hd by invoking or instantiating create renditions for every single file or a small groups.