Problem: DIP status not updating after deletion from the Storage Service

[shij13]

Expected behaviour In storage service, after “Delete” action is confirmed for a DIP:

• Status updates to “Deleted”
• Current Location link is no longer live
• Actions column clears to show no options

In backend storage, the file is deleted.

Current behaviour In storage service, after “Delete” action is confirmed for a DIP:

• Status remains as “Uploaded”
• Current Location link is still live and download dialog opens when clicked (file size is indicated as 0 bytes)
• Download and Delete options still appear in Actions column as live links Clicking Download opens download dialog (file size is indicated as 0 bytes)

Selecting Delete opens confirmation pop-up. Confirming deletion results in an error: “Package deletion failed. Please contact an administrator or see logs for details.”

Log indicates the file is deleted from storage: INFO2022-11-23 08:55:21 locations.models.s3:s3:delete_path:193: S3 path to delete [package location] begins with /; removing from path prior to deletion WARNING 2022-11-23 08:55:21 locations.models.s3:s3:delete_path:206: No packages found in S3 at: [package location] ERROR 2022-11-23 08:55:21 locations.views:views:package_delete:235: Package deletion failed: No packages found in S3 at: [package location]

This behavior has been observed for three DIPs so far, each in a different production instance. For one package, the status and Actions column successfully updated after restarting the instance, but we'd like to debug further to prevent this issue in the future and avoid having to restart instances each time it occurs (if it occurs again).

Steps to reproduce This issue has appeared inconsistently for packages in production, and we have not been able to reproduce it in a dev instance yet. The following steps have been attempted to reproduce the issue in dev. Once an AIP and DIP are created:

• Delete the DIP then the AIP via storage service only (i.e., don’t send a deletion request from the dashboard for the AIP)
• Send a deletion request from the dashboard for the AIP, delete the DIP in the storage service, then approve the deletion request for the AIP in storage service
• Request and approve deletion of the AIP in the storage service only, then delete the DIP from the storage service
• Send a deletion request from the dashboard for the AIP and approve the request in storage service, then delete the DIP in the storage service

Update will be posted if the issue is successfully reproduced or the conditions for creating the issue are more concretely determined.

Your environment (version of Archivematica, operating system, other relevant details) CentOS 7, AM 1.13.x, SS 0.19.x

---

For Artefactual use:

Before you close this issue, you must check off the following:

• [ ] All pull requests related to this issue are properly linked
• [ ] All pull requests related to this issue have been merged
• [ ] A testing plan for this issue has been implemented and passed (testing plan information should be included in the issue body or comments)
• [ ] Documentation regarding this issue has been written and merged (if applicable)
• [ ] Details about this issue have been added to the release notes (if applicable)

[sromkey]

Hi @shij13 , we're just going through some older issues. Is this something that continued to be an issue for you? We did some documentation recently on s3 permissions and are curious if perhaps this was happening specifically in s3 DIP storage spaces. Let us know if you have any intel or feedback, thanks!

[shij13]

@sromkey apologies for the delayed reply! This issue doesn't occur consistently. It's been noted a handful more times since reporting the issue.