We have a workflow that receives email from another system and parses it to send SMS messages. We noticed that an important email was not received by Pipedream, and went back to debug the reason why. This workflow uses an xxx@pipedream.net based email workflow, where the other system emails Pipedream directly.
We noticed that the inbound email that was not received included image attachments. So we sent emails with no attachment, or with non-image based attachments (i.e. a text file or a Word file), and everything worked fine. However, a jpg, gif, etc resulted in no email being received by our workflow at all. Clearly there is something hard breaking in the code when Pipedream receives emails with image attachments.
This seems like a pretty nasty bug, and yet one that is somewhat undercover, as it doesn’t apply to all attachment types or all inbound emails. Please research and fix ASAP.
Yes, that helps a lot. And no, it’s not obvious at all. You should absolutely log an error or exception when the email exceeds that size, at the minimum. Or, what I would prefer, store the body of the email (up to 150kb limit), and then send the whole email to the other endpoint used for large emails, and then log an exception that in order to get all content you have to switch to that endpoint.
For our use case, we are parsing information submitted to a ticketing system and then kicking that out to our maintenance team via SMS; Pipedream receives the email from the ticketing system, parses it, then sends the SMS. We don’t control what size email the customer sends in, and therefore we don’t control whether this endpoint ultimately fails to do what it’s supposed to do or not. We don’t care what attachments are in the email, we just want the text in the body. So for our use case, we would happily discard the attachments and take the body of the email…