Email monitor attachment error
Hello
I'm seeing an error in an email monitor that I'm not sure how to decipher. The attachment is a 1M, 500+ page PDF. Other attachments seem to be processing fine. This issue has only been happening the past couple of weeks. Would this be related to disabling legacy email services? We do have a security scanner in place for attachments, and I suspect the monitor may be trying to process the email before the scan completes. Most attachments are significantly smaller in size and may finish scanning in time.
Error message in the log:
Unable to upload attachment [Device_change_Audit_20211022_083256_878.pdf] for email [143227004.2157.1634909579687.JavaMail.root@prime1-prd], but email processing will continue.: Response status code does not indicate success: 400 (FileContents must not be empty.
Parameter name: FileContents).: at Tdx.RestProxy.Core.Proxy.RestProxyBase.EnsureSuccessfulResponseAsync(HttpResponseMessage responseMessage)
at Tdx.RestProxy.Core.Proxy.RestProxyBase.<>c__DisplayClass10_1`2.<<ExecutePostAsync>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at Tdx.Core.Threading.MultiThreadObject`1.LockAsync(Func`2 lockedFunc)
at Tdx.RestProxy.Core.Proxy.RestProxyBase.ExecutePostAsync[TContent,TResponse](String uri, TContent content, Func`2 onRetryFunc)
at Tdx.Email.Monitor.Core.ApiProxy.TeamDynamixInternalWebApiProxy.UploadAttachmentAsync(UploadAttachmentRequest request)
at Tdx.Email.Monitor.Microservice.EmailProcessor.Utility.AttachmentUploader.UploadAttachmentsAsync(Int32 partitionId, Int32 billableEntityId, Guid userId, Nullable`1 parentItemId, Nullable`1 itemId, Int32 componentId, String emailId, List`1 attachments, ITeamDynamixInternalWebApiProxy proxy, IEmailMonitorComponentLogger componentLogger, CancellationToken token) in /app/Tdx.Email.Monitor.Microservice.EmailProcessor/Utility/AttachmentUploader.cs:line 109
Thank you,
Pam
Answer (1)
Hello Pamela,
When I've seen this error in the past and the client has attachment scanning active, that scanner is the most common culprit for why the attachment isn't able to be uploaded at the time the message is processed.
If it is that large perhaps the user ought to instead be directed to upload the file after their ticket generates so it doesn't have to go through the attachment scanning process of your mail system.
TDX does have our own security around attachments so we would not allow them to upload anything malicious in nature.
Let me know if that would work.
Sincerely,
Mark Sayers
Sr Support Consultant, CS
The message in question is a daily report auto-generated by one of our system monitors, so we're looking into what other options we have. It's certainly likely that other attachments will get caught up over time, so we need to think about those as well.
-Pam - Pamela Jordan Fri 10/22/21 12:27 PM