[6.x] Added ability for postmark transport to throw errors #30799
Conversation
GrahamCampbell
changed the title
|
And how to go if someone (implicitly) depends on the old behaviour? Maybe it should be done via a config (and have the sane default to enable it, exceptions shouldn't be silent in such case). But maybe this change in behaviour should rather target 7 |
Perhaps I don't see the downsides but I can not really think of a way in which this would negatively impact an application. The only thing this would be doing is providing an exception where there should be one because there is also no other way to currently detect anything going wrong in this process. Especially when you have set up error reporting in the form of something like Sentry this would be a massive help. Setting the target to 7 it also being too precautious because I have already wasted time on this black box which shows no errors and I can imagine other have done or will do the same. |
|
I wonder if this means that previously, email sent on a queued job that failed on the Postmark end wouldn't end up re-running because no exception was thrown - the job would just finish and the email lost. Makes sense to me that an exception would be thrown so that the job would be attempted again. |
|
I definitely think throwing an exception is the expected behavior. I didn't know they were being silenced. |
I just spent about an hour trying to debug why the postmark driver was not working. All thrown exceptions are currently not handled and fail silently.
By registering the plugin included in https://github.com/wildbit/swiftmailer-postmark package it will allow for exceptions to be thrown when the Postmark API does not deliver a HTTP 200 response.
A minor adjustment with a huge impact when it comes to debugging and actually detecting issue in production.
Perhaps this file is not the ideal candidate to register the plugin in but you get the idea. I hope this will be open for discussion if this is not the ideal solution.