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:

1. Create a new project.
2. Upload a session to it.
3. Create a new empty session in the project via the UI. (No scans, no data).
4. Delete the empty session.
5. 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:

1. "Empty" is definitely relevant. From a bunch more tests, it looks like "empty" essentially means "no resources found to delete". That is...
   1. If you add a scan to your empty session but there are still no resources, the bug still occurs.
   2. If you add a resource (even with no files) to the empty session, even with no scans, the bug does not occur.
2. "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.