Issue

Cancelling an upload or deleting an uploaded file in the Attachment field prevents users from attaching the file a second time. 

Symptoms and Impact

Users receive "File already exists" errors when attempting to re-upload files with the same name after deletion.  This leads to confusion and inconsistent user experience. 

Steps to reproduce

1. Enable repository storage for attachments.  

2. Add an Attachment field to your View. For more information, see Configuring Views.  

3. In Pega Constellation, use an Attachment field to upload a file to a work object.  

4. Click Cancel or Delete to remove the file. 

5. Re-upload the file using the same name. Result: Error is seen onscreen:
   "The specified file/folder already exists in the target repository. Please specify a different file/folder."
    

Root Cause

This issue has been identified as a product feature gap.  

In Pega Constellation, when using Attachment fields, the upload and attach processes are separate. 

In a Flow Action which uses an attachment field, when a user adds a file, it creates a temporary attachment object, which gets stored in the repository, but is not attached until the Flow Action is submitted.   

Similarly, after adding a file, if the user deletes the file, the removal of the temporary attachment from the repository does not persist until the Flow Action is submitted. 

This issue is particularly problematic in scenarios where process flows encountered exceptions during file creation, as the attachment wll persist in the S3 repository while the database transaction rolls back, creating an inconsistent state between the repository and database records. Investigation showed this is caused by insufficient cleanup of repository artifacts when attachment operations failed or were 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 activity pyFormatAttachmentName has been modified to prefix Case ID and append timestamp.  Using FileName as an example, and for scenarios where Case ID exist, the format will be as follows:  

<CaseID>_FileName_<TimeStamp>.<extension> 

This ensures that each uploaded file gets a unique identifier even if it's the same document being reuploaded. This prevents the system from confusing it with the previously discarded file. 

Due to this change in the file name, users still have the ability to upload the same file multiple times.  In the new release, there is a background process that runs periodically to clear out orphaned attachments left in the repository.  Synchronization between repository and database operations now ensures complete cleanup of attachment artifacts during rollback scenarios and improved handling of duplicate filename conflicts.

Workaround

Use the below local changes in releases where the fix is not yet implemented: 

A) Override activity  pyFormatAttachmentName to append a timestamp to the file name.  

Note that this removes the duplicate file restriction. 

B) After any Delete action, ensure that a Save or Submit is processed to ensure the delete call is sent to the server. 

References

Configuring Attachment fields 

File is not removed from repository after attachment upload failure and Case is moved into ProblemFlow  

Why Constellation's file attachment input field uses display: none 

Deleting an attachment does not delete the document in the repository  

Storing Case attachments using external storage