Issue

During an attachment upload to repository storage, when an error scenario causes a rollback, the attachment file is not removed from the repository.  The Case goes into Problemflow (Assigned to Broken process).

Symptoms and Impact

If a database COMMIT fails while writing the attachment from Data-WorkAttach-File to the repository, the same attachment cannot be created in the repository on subsequent attempts, as it already exists in the folder. 

After addressing the failure, the following error occurs when reuploading the file: 

"The specified file/folder already exists in the target repository. Please specify a different file/folder."

 Cases are moved to a problem flow when exceptions occur at runtime, capturing the error details in a problem flow assignment. 

Steps to reproduce

1. Enable repository storage for attachments. 
2. Attach a file to a work object. 
3. Reproduce/Simulate a repository connectivity issue during the file attachment.
4. Address the source of the failure. 
5. Reupload the file using the same name. 
6. The system moves the case to Broken Processes with the error:
   "The specified file/folder already exists in the target repository. Please specify a different file/folder."
    

Root Cause

A defect in Pega Code/Rules where the associated Link-Attachment and Data-WorkAttach-File objects in the database are rolled back, but the file on the repository is not rolled back. 

This issue is particularly problematic in scenarios where process flows encountered exceptions during file creation, as the attachment persist in the S3 repository while the database transaction rolled back, creating an inconsistent state between the repository and database records.

The environment remains in a state with insufficient cleanup of repository artifacts when attachment operations fail or are reversed, leaving orphaned files that blocked subsequent uploads with identical filenames.

Solution

This issue is resolved in the following Pega Infinity releases:

Pega Infinity '25.1.4
Pega Infinity '26.1.1

The latest releases have synchronization between repository and database operations to ensure complete cleanup of attachment artifacts during rollback scenarios caused by browser abandon, network interruption, node restart, or unexpected transaction failure.

There is also improved handling of duplicate filename conflicts. The logic has been updated to display the file name in the pyFormatAttachmentName activity by prepending the CaseID (if available) and appending a timestamp.  This will prevent orphan repository artifacts during normal cancel, rollback, and failed-submit paths by explicitly cleaning up temporary attachment state. 

Workaround

An interim workaround is to adjust the file name to allow the upload to proceed. 

One way to do this automatically is to append a timestamp to the filename via an override of CallVirusCheck. 

For  details on  the CallVirusCheck extension point see Extension points and supporting Rules for attachments and Performing a virus scan on an attachment.

References

Storing Case attachments using external storage  

File upload and download troubleshooting FAQs