Deleting an attachment does not delete the document in the repository

General
,
1

Hi,

Whenever we delete an attachment in a file input:

image
image975Ă—281 63.5 KB

image
image975Ă—258 56.9 KB

Then reupload the same file, it results in the error shown below.

image
image1449Ă—525 36.6 KB

It appears that the document is only deleted from the repository when we submit or save the assignment, and not when we click delete option.

Do we have some workaround for this issue?

2

HI @VonRafaelR16606415

Few questions from my end

  1. What is the version of Pega you are using ?
  2. Is the storage defaulted to Pega DB or an external repository ?

For the error you are encountering you can refer to the below PDN Docs article

Below is the same error mentioned in the documentation.

image
image1966Ă—916 84.7 KB

Attachment Upload Behavior in Pega Constellation

1. POST /attachments/upload

When an attachment is uploaded using the POST /attachments/upload API (for example, during case creation in a form), Pega first creates a temporary attachment instance.

  • The API returns a unique attachment ID to the client.
  • At this stage, the attachment is stored as an instance of Data-WorkAttach-File-Temp in the pegadata.pc_data_file_temp table.
  • This temporary attachment does not yet have a Link-Attachment relationship with a case, so it is effectively an orphan attachment until the case is created or updated.

This behavior is independent of the configured attachment storage option:

  • Database storage – the file content is stored in the Pega database.
  • Repository storage – the file content is stored in the configured external repository.

In both scenarios, a temporary attachment record is created first.

If the user cancels the operation (for example, cancels case creation, delete action):

  • The temporary attachment remains in the temp table.
  • Pega automatically cleans up the temporary attachment after ~2 hours (Did not verify this but hope it works that way)
  • If the storage option is repository, the file is also removed from the repository during the same cleanup process. There were some fixes done in v25.1.2 patch regarding this cleanup which i have to check more in detail.

image
image2696Ă—106 56.5 KB

image
image2074Ă—298 123 KB

2. POST /api/v1/cases – Case Creation or Save

When the case creation API (POST /api/v1/cases) is invoked:

  • The temporary attachment ID returned from the upload API is passed to Pega.
  • Pega links the attachment to the case during case creation or save.
  • Once the case transaction is committed, the following happens:
    • The record in pegadata.pc_data_file_temp is deleted.
    • A permanent attachment instance of class Data-WorkAttach-File is created in the pegadata.pc_data_workattach table.

Again, this occurs regardless of the storage option configured:

  • Database storage → file content stored in the Pega database.

  • Repository storage → the attachment metadata is stored in Pega, while the actual file content is stored in the external repository.

Hope this helps

Regards

JC

3

Thank you for your detailed explanation @JayachandraSiddipeta

  1. we are using v25.1.2
  2. we store the attachments in a repository

does that mean we need to wait for a certain time before we can reupload the same document unless we save/submit the assignment?

4

No need to wait to upload again. The error message mentioned by you could be because the storage repository might not be responding due to intermittent connectivity issues.

Check the tracer and logs to see if you have any specific error.

I am in 25.1.2 and have tried to delete the file and re-upload again. It works flawlessly. Below is my setup.

image
image1792Ă—770 122 KB

You can try checking the prompt checkbox and see if you get any prompt or alert. I did not get any from Work Portal.

After you upload the content on the UI and just before you save the assignment (For the first time), do check for below things

  1. Is the data-workattach-temp instance created?
  2. Is the content uploaded to repository ?. Check using D_pxGetFile data page by passing relevant parameters.

Now do the same checks after the assignment save and also when you execute delete action as well.

Hopefully you will find the error pattern and also the root cause.

Let us know

Regards

JC

5

As JC mentioned, this works fine in 25.1.x version. If you ccheck your network tracer, it will perform the disassociate the deleted doc ID once the assignment is submitted .

{“target”:“.ExtractPlanMemberInformation”,“instruction”:“DELETE”}]

6

@JayachandraSiddipeta

We have the same configuration but it still throwing the same error.

When we initially upload a document without saving the assignment:

  1. Data-WorkAttach-File-Temp instance is created

    image
    image1453Ă—363 14.3 KB

    image
    image639Ă—444 26.1 KB

  2. Content is uploaded to repository

    image
    image555Ă—598 20 KB

Then if we execute delete action, no rules are triggered in the tracer unlike when we save the assignment where pxDelete is getting called.

7

@VonRafaelR16606415 I observe same behavior in 25.1.2.

Steps:

  1. Upload an attachment using an attachment property but not the attachment gadget in utility bar (immediately it creates a Data-WorkAttach-File-Temp and also uploads it to repository)
  2. Delete it without clicking on Save/Submit (Now there is no action from system, ideally it should delete the Data-WorkAttach-File-Temp instance which will delete it from the repository as well. This delete is only happening when you save the case.)

And as the previous file is actually not deleted in the repository, I believe system is throwing an error if we upload the file with same name. This seems to be an issue with the platform. Please raise an INC so that they can investigate further.

If you need an immediate fix, pyFormatAttachmentName - In this rule, append current datetime stamp to your file name so that its always unique and there will be no error when you try to upload the file name again immediately after deleting and without saving the case.

image
image1375Ă—346 26.4 KB

1 Like