Module now silently falls back to null transport if there is no valid transport

The warning in the log could work, but I thought of another way. What if we create a new ErrorTransport and return that from TransportsFactory in this case? The ErrorTransport's job is simply to throw an Exception any time someone tries to send an email. That exception is then caught by the work we did in 🐛 SymfonyMailer::mail should handle other exception types Fixed , and the normal email failed message is displayed. A more detailed message from the exception is in the logs.

I tested this, and it seems to work. I added an MR to this issue. Can you test it to see if it works for your use case?

Not directly related to this, but FYI, we did remove the ability to delete your default transport in 🐛 Setting symfony_mailer_lite.settings.default_transport not guaranteed to be set Fixed . That may affect the way you're configuring your sites, since it's now harder to get into a situation where you have no transports.

I just want to document this, really. This isn't an issue for us anymore, the reason we initially had the exception and then the null transport is that our transport existed but was invalid (an smpt transport without the required host field). We changed it to host localhost now, which doesn't work, but is technically valid config, tries to send, fails and then throws an exception, resulting in the old behaviour if displaying an error message when mail configuration is invalid/disabled.

I suppose an error transport works too, whatever you are comfortable with as a maintainer :)

I merged this change. Now, when no transports are configured, the system will display the generic core email failed error. The detailed message about the unconfigured transports is available in the error log.

Automatically closed - issue fixed for 2 weeks with no activity.