Deleting a bitstream via item bitstream administration leaves orphaned bitstreams

[saschaszott]

Problem Description

In the item bitstream administration, bitstreams can be deleted individually within their bundles. However, we observed that clicking the Delete button only removes the relationship between the bitstream and the bundle (i.e. the corresponding entry in the bundle2bitstream table).

The bitstream itself is not removed:

• the physical file remains in the filesystem / asset store
• the entry in the bitstream table is not deleted
• the metadata of the bitstream is still present (in metadatavalue table)

As a result, the system may accumulate orphaned bitstreams that are no longer associated with any bundle.

In our DSpace 8 based instance, the following SQL query currently returns multiple results, indicating the presence of orphaned bitstreams:

select * from bitstream
where uuid not in (select bitstream_id from bundle2bitstream)
  and uuid not in (select bitstream_id from process2bitstream);

Expected behavior

Deleting a bitstream via the item bitstream administration should fully remove the bitstream, including:

• the file from the filesystem / asset store
• the database entry in the bitstream table
• all associated metadata

Alternatively, if the intended behavior is to only remove the bundle–bitstream association, the UI should clearly communicate this to administrators.

Bug Analysis Results

Is it possible that clicking the Delete button triggers an incorrect REST request? Currently, a PATCH request is sent to the /api/core/bitstreams endpoint. Instead, a DELETE request should be used (according to this part of the REST contract 👉 https://github.com/DSpace/RestContract/blob/main/bitstreams.md#delete-method)

[saschaszott]

The PATCH request initially only marks the bitstreams as deleted; it does not actually remove them. The bitstreams are only physically deleted (both from the database and the asset store) when the cleanup CLI command is executed.