Sendmail transport throwing unneccessary exceptions on worker restart #54532
Labels
Comments
|
So, this seems to be a bit more broken than only on worker exit. When the worker is still running when having received an SMTP timeout, but needs to send a new email, it will now throw invalid stream resource errors. I assume this is because the stream is no longer being set to null when the initial exception occurs when the worker tries to restart the process as it had received the timeout. When trying to restart the worker when this happens, another error is thrown. |
|
We are seeing some emails not being send out recently and lots of "SMTP command timeout - closing connection" errors in the logs. Could this issue also cause emails being dropped? Using latest Symfony 6.4 |
|
When using messenger it should (when configured correctly) be retried or placed in the failed queue. If the worker did not restart soon enough to create a new connection before the last send retry and you do not have a failed queue, it can be dropped. |
|
We have the same problem, exactly described as @bobvandevijver dit. We are using "symfony/mailer": "6.4.4" for now so our mailings can continue. |
|
@lazka / @peter-otten Maybe you can try #54532 to verify whether my proposed fix solves your issues as well. |
fabpot
added a commit
that referenced
this issue
May 30, 2024
…active mode (bobvandevijver) This PR was squashed before being merged into the 5.4 branch. Discussion ---------- [Mailer] Fix sendmail transport failure handling and interactive mode | Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no <!-- please update src/**/CHANGELOG.md files --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Issues | Fix #54532 <!-- prefix each issue number with "Fix #", no need to create an issue if none exists, explain below instead --> | License | MIT #54239 introduced an issue for us when using sendmail in interactive mode using a long running background worker. It will throw exceptions due to an unclean shutdown in case of an SMTP timeout (5 minute by default), while in interactive mode all output is actually handled by the SMTP transport, including that timeout. That makes the exit code of the long running process not relevant in that mode. See the bug report for some more details. I have verified that this change solves my production issues, although I am not particularly fond on the hoops I had to jump to show this in the test. cc `@aboks` Commits ------- 1b2ead3 [Mailer] Fix sendmail transport failure handling and interactive mode
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Symfony version(s) affected
7.0.6, 6.4.6, 5.4.38
Description
Due to bugfix #54239 the sendmail transport is now throwing an unnecessary exception on messenger worker exit when used in combination with the
-bsoption (which is the default), where the sendmail process stream is actually being wrapped with an SMTP transport instance.When used together with the SMTP transport the sendmail process is kept running in the background, and will at some time (depending on server configuration, default 5 minutes for Exim) output an SMTP command timeout. This is normally handled by the SMTP transport when a new message needs to be send, which automatically restarts the transport when necessary (although I haven't been able to verify what happens with the #54239). Instead, it will trigger an exception on worker exit for something that is not necessary.
How to reproduce
Possible Solution
Wrapping the terminate lines for the embedded streams might be enough, but might also have unintended side effects I am not aware of as the stream is a common process stream.
symfony/src/Symfony/Component/Mailer/Transport/Smtp/SmtpTransport.php
Line 213 in de1409e
symfony/src/Symfony/Component/Mailer/Transport/Smtp/SmtpTransport.php
Line 272 in de1409e
Additional Context
Messenger log:
Exim log:
The text was updated successfully, but these errors were encountered: