I was dealing with a third party service provider similar to Mailchimp, using their API to send out our e-mail when the Rails application started breaking due to raising exceptions. There is nothing wrong with that except for the fact that the error message from the library of this service was so big that was actually making a worker process fail due to the lenght of the message. The message actually contains a huge payload with even a hole PDF data in it.
The worker process on the server was not exprecting to deal with the contents of a PDF and a string with this dimention and so was breaking all the times.
In order to solve this issue we had to manipulate and cut the error message. This is obviously not cool and it a waste of time and moeny due to - I call them - unethical error messages.
I understand that you want to be as explicit as possibile with the errors but returning a pdf file in it for debugging is not maybe the smartest thing to do. So please remember, when returning an error try to be concise and return something that other developer are expecting and other applications (which you never know) can deal with. We can have a lot of RAM and a big number of processors but being conservative and not wasting resources it’s still an option.comments powered by Disqus