v0.3.7: Improved delivery error handling #93
Closed
wneessen
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
This release introduces the
SendErrortype which satisfies the error interface and provides a better way to identify delivery errors. A newsendErrorfield has been added to theMsgas well, to also allow per-message error handling in bulk mailings.We've also added different
SendErrReasonthat indicate the different things that can go wrong during mail delivery. These reasons can be checked for, for eachMsgusing theerrors.Ismethods. Alternatively, theerrors.Asmethod can be used to unwrap theSendErrorto get access to it's methods. TheSendErrorprovides aIsTempmethod that returns true if the delivery error is of temporary nature.This is useful for delivery retries. For example the following code could be used to decide whether the error is retryable or not:
If the
Sendmethod runs into more than one error during delivery, these errors are accumulated and returned with the reasonErrAmbiguous, since it's not possible to exactly say what caused the error. For this it comes handy, that the*Msgnow provides per-message send errors. The*Msgnow hasHasSendError(),SendErrorIsTemp()andSendError(). WhileHasSendError()simply returns a bool in case a*Msgfailed during delivery andSendErrorIsTemp()returns true if it's a temporary error, theSendError()will return the fullSendErrorerror of the corresponding*Msg.The
Error()method ofSendErrorwill return a detailed error string based on the accumulated errors that were collected during the delivery.Thanks to @imirkin and @iwittkau for providing valueable feedback and performing code review on the PR.
What's Changed
Full Changelog: v0.3.6...v0.3.7
This discussion was created from the release v0.3.7: Improved delivery error handling.
Beta Was this translation helpful? Give feedback.
All reactions