Bulk image deletion

[nathanielrindlaub]

Right now, users can delete images via bulk-selecting them and clicking "delete images", but because it's not implemented as an async task, we limit it to a maximum of 500 images at a time to prevent timeouts. It would be great to support the deletion of more images now that we have the async task management service in place. I think this would involve the following:

1. A button to delete all images that are currently filtered. Perhaps this button should live at the bottom of the filter panel, along side the "get info" and "data export" buttons? Maybe it's time for a hamburger-esque menu button down there to store this and other actions we might want to apply to all images matching the current filters as it's getting a little crowded.
2. Create a mutation resolver and task handler in animl-api for deleteImagesAsync that can accept filters as an input. We should keep the current deleteImages mutation & workflow to allow for users doing the bulk-selection or individual image approach.
3. A UI to display the state of the async task and display errors.

[nathanielrindlaub]

I'm actually not sure that we did end up setting a maximum number of images we could delete? I can't find any indication that we did in the the frontend or animl-api code. So a first step would be to stress test how many images deleteImages can handle before timing out.

[nathanielrindlaub]

It does not appear that there is any kind of limit on how many images a user can delete at once. In this instance, a user tried to delete 2304 images in one go and the GraphQL Lambda timed out. I'm not sure exactly how many were successfully deleted, but I assume the actual threshold is much lower.

@jue-henry, let me know when you have a chance to test out how many images the GraphQL Lambda can delete comfortably? I think once you've done that I'll temporarily put a limit on the delete images operation until this is implemented so users don't run into issues again.

[jue-henry]

@nathanielrindlaub I did a rough benchmark and I think 100 images might be a good break point. I first started with deleting 1k images, and got an error which seems to be when node hits its limit of open sockets, and only about 100-150 images got deleted before erroring out. So then I tried 100 images and it took about 3.5 seconds to delete, and I think thats a pretty good spot honestly. But let me know if you want me to push this higher

[postfalk]

From an architectural, database perspective, I would be careful to delete along search results (it would be even more problematic if we were to use a search engine because at some point direct database search might become unwieldy). If it was my decision I would allow for:

a) Manually checking pictures from a search result and then delete
b) Delete along existing hierarchy: dates, deployments, projects, etc. as already suggested in the camera part

I feel with an API delete on research results we are softening some very useful principals of API design.
Let's discuss

[postfalk]

An additional thought, deleting on search results would lead to situations where the user has a hard time to fully understand the consequences of their action.