You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, I would like to express my appreciation for this project; especially for the ability to use multiple data stores. I have been able to use it with redis successfully. Thanks!!
I have a suggestion:
I have had a scenario where one or more transports were misconfigured (typo in smtp credential). But there were no errors because the other transports were working just fine, and the emails got sent.
We are currently able to pass an error handler through opts.onError. But this gets called only when the sending of email fails, and all attempts are exhausted. As long as a functional transport exists, opts.onError will never get called; and we can't identify the misconfiguration.
It would be great if we could specify some form of configuration/error handler that will get called when a particular transport consistently fails. This will allow us to catch misconfigurations, and provide feedback if the smtp server is no longer available (for whatever reason).
The text was updated successfully, but these errors were encountered:
First of all, I would like to express my appreciation for this project; especially for the ability to use multiple data stores. I have been able to use it with redis successfully. Thanks!!
I have a suggestion:
I have had a scenario where one or more transports were misconfigured (typo in smtp credential). But there were no errors because the other transports were working just fine, and the emails got sent.
We are currently able to pass an error handler through
opts.onError
. But this gets called only when the sending of email fails, and all attempts are exhausted. As long as a functional transport exists,opts.onError
will never get called; and we can't identify the misconfiguration.It would be great if we could specify some form of configuration/error handler that will get called when a particular transport consistently fails. This will allow us to catch misconfigurations, and provide feedback if the smtp server is no longer available (for whatever reason).
The text was updated successfully, but these errors were encountered: