Is there any file upload elements in your form? Could you check the value of that file upload element for failure cases (by debugging or looking at the database)?
I guest that there are some users uploading file within unallowed file type. For example: you have only media types for pdf and image but I uploaded a word file. So what's happen?
You won't see file upload value in that submission view but there is still invalid file upload value behind the scene.
It turns out the problem submissions were ones with stored data against an upload field but where the source of that field value was empty.
Looking into the code behind DeleteUploadFile
...
string source = propertyBag[elementName].ToString();
string[] separators = new string[1]{ "|" };
foreach (string splitBySeparator in source.SplitBySeparators(separators))
{
IContent content = this._urlResolver.Service.Route(new UrlBuilder(splitBySeparator));
if (content != null && content is IContentMedia)
this._contentRepository.Service.Delete(content.ContentLink, true, AccessLevel.NoAccess);
}
...
if source is an empty string then SplitBySeparators returns null so this line was the cause of the NullReferenceException I was seeing.
When I then tried to process each submission manually, the FormatException was caused by the fact that the submission id's seem to be stored in a string like "8658704:CFA0CC6C-2973-493E-A3A8-B6C05DC07DA8". When these ids are passed into DeleteSubmissionData it must extract the guid. However, the same is not true with SaveToStorage - it wants the submission passed in to already be just a guid.
So, I've managed to solve the problem and my job now removes these problem submissions. The code isn't very pretty though I'm having to catch exceptions, manipulate the submissions and then try the alternative approach of clearing.
We have a scheduled job almost identical to the one detailed here : http://www.herlitz.nu/2018/10/15/episerver-forms-cleanup-for-gdpr/ for deleting user data when that database is used in a non-production environment. When this runs there is an NullReferenceException exception thrown on 3/70 forms when its attempting to delete the submissions
I then tried clearing one submission at a time on the problem forms
which revealed that there was one submission each form that had an issue and the exception is now a FormatException
If I create a form submission myself I can see that the id of the submission was 8658704:CFA0CC6C-2973-493E-A3A8-B6C05DC07DA8 and there is no exception when it is cleared by the job.
But for one of the submissions that is throwing the exception the submission id is 7883982:5D8D3B79-D542-4543-BF59-21786095E7F5 which looks valid but still throws that exception.
My plan was to alert us to the exception with information about the form and the submission id so that we could go to the Production CMS, find that submission and delete it so that it wouldn't bother us again. I've discovered though, if I select that single submission in the CMS and click Delete, then I get the NullReferenceException again and the submission isn't deleted.
However, if I select all entries on the form and then click the Delete icon then it does clear all the form submissions without any issues. Deleting all the submissions in Production isn't something that we can do or the client wouldn't be very happy!
I'm wondering if anyone could
a) Suggest what might be wrong with the form submission and a way to fix or delete it. The stack traces suggest it might be something to do with the uploaded file on the submission, but looking at them in the CMS there is no file upload shown on the submission - perhaps it has a partial record of an upload?
b) Help me understand how the submissions are deleted en masse from the CMS Delete icon when all form items are selected so that I can use this different approach in the scheduled job.
For some background, the site has recently been upgraded from EPiServer 9.10 to EpiServer 11.11 and its hosted in DXC. However, all the problem submissions are prior to the upgrade.
Thanks
Ed