Cannot delete "terminated" user study in fastcompare

[luk27official]

Once again, this issue happens in the ndbi021 branch, not sure about other ones.

Sometimes, the initial computation takes too long and the user might want to shut it down to preserve resources. The problem is that when the user shuts down the environment (i.e. Docker), the server stops and the study is not activated, which is expected. But, when you turn the server on again, the user study cannot be deleted as it is in an unactive state. By the way, this can happen not only on behalf of the user, but also any time some service crashes.

The study then looks like this, it seems like it is still loading but that will never happen as it was terminated and now there is no way to remove it from the list (the study in the screenshot was created over a month ago).

[pdokoupil]

Some background: Not being able to delete "non-activated" studies was an intentional decision. Normally, you would like to be able to do so and ensure that such an action would trigger proper cancellation of the study initialization. While this would be possible, I do not think the time effort would be worth it. Since this was very annoying when people have tried to to add new algorithms and accidentally made a mistake that was causing Exception to be thrown during initialization (leading to permanently inactive study), I added some basic 'initialization failed' error reporting, that transitions the study into inactive, but failed state, where the study can be removed again.

Forcefully shutting down the container won't be caught by that mechanism, since there is no exception being thrown. I am not sure what would be the best approach here, probably proper cancellation, but taking time/benefit tradeoff into account, I would say that we can perhaps just check all non-active studies during server startup, and mark them as failed (if they are not active after fresh start, they would likely stay in that state forever). @luk27official What that resolution work for you?

[luk27official]

I believe the approach that you mentioned would be a viable option, or it would be a nice option to have a script which would just get an id (or a list of ids) of studies that would be deleted on execution of the script; I believe the second option would be even easier to implement as there is already the deletion mechanism somewhere. There is no need for an over-complicated solution, but having any option to delete the study easily would be fine.