1.8.1, 18.104.22.168, 1.8.2, 22.214.171.124
Here's the original report emailed to the bugs address:
Failed "Delete session" action uncontrollably triggers massive deletion of bulk sessions (including their scans) in version 1.8.2
I had to shut down the engine, 26 sessions were gone but not the one I wanted to delete.
Triggered by mozilla firefox 87.0 (64-bit) under ubuntu 18.04. Also triggered by pyxnat, and by other members of the team using the engine with different browsers.
We run a private instance of the server in a VM in AWS.
UPDATE: it's quite real. I'm a little constrained in my test system capabilities at the moment, but this seems to be reproducible like this:
- Create a new project.
- Upload a session to it.
- Create a new empty session in the project via the UI. (No scans, no data).
- Delete the empty session.
- Check the backend. The entire archive dir for the project is missing.
The "empty" part in the empty session does seem to be important, as when I uploaded 2 sessions via the compressed uploader and then deleted one of them, I didn't encounter this issue. There's still a lot of possible lurking variables, however.
UPDATE2: I would like a pure XNAT environment to have more confidence in this, but I think I have some additional details:
- "Empty" is definitely relevant. From a bunch more tests, it looks like "empty" essentially means "no resources found to delete". That is...
- If you add a scan to your empty session but there are still no resources, the bug still occurs.
- If you add a resource (even with no files) to the empty session, even with no scans, the bug does not occur.
- "Empty session" is not required to actually be a session (xnat:imageSessionData). I can recreate this with other generic subject assessors, but not session assessors or subjects.