Problem
MailerGenericBuilder.async() is intended as a preconfigured default so callers do not need to pass async flags manually. That default applies to both sending mail and testing the SMTP connection.
Currently sendMail(email) honors the builder-level async default through operationalConfig.isAsync(), but testConnection() delegates directly to testConnection(false) and therefore always runs synchronously.
There is a second asymmetry in the explicit async path: sendMail(..., true) falls back to Simple Java Mail's built-in async handler when batch-module is not present, while testConnection(true) directly loads batch-module and fails when that optional module is absent.
Expected behavior
When a mailer is built with .async(), calling:
should behave like:
mailer.testConnection(true);
and return immediately while the connection test runs through the configured async execution path.
When batch-module is available, async connection testing can use it. When batch-module is absent, async connection testing should still work through the built-in async handler, matching the behavior of async sendMail(...).
Current behavior
mailer.testConnection() blocks because it hardcodes false, regardless of the builder-level async configuration.
mailer.testConnection(true) requires batch-module, even though async sending already has a built-in fallback.
Notes
This came up while triaging #608. The no-arg method blocking is valid for a normal synchronous mailer, but not for a mailer explicitly configured with .async().
Problem
MailerGenericBuilder.async()is intended as a preconfigured default so callers do not need to pass async flags manually. That default applies to both sending mail and testing the SMTP connection.Currently
sendMail(email)honors the builder-level async default throughoperationalConfig.isAsync(), buttestConnection()delegates directly totestConnection(false)and therefore always runs synchronously.There is a second asymmetry in the explicit async path:
sendMail(..., true)falls back to Simple Java Mail's built-in async handler whenbatch-moduleis not present, whiletestConnection(true)directly loadsbatch-moduleand fails when that optional module is absent.Expected behavior
When a mailer is built with
.async(), calling:should behave like:
and return immediately while the connection test runs through the configured async execution path.
When
batch-moduleis available, async connection testing can use it. Whenbatch-moduleis absent, async connection testing should still work through the built-in async handler, matching the behavior of asyncsendMail(...).Current behavior
mailer.testConnection()blocks because it hardcodesfalse, regardless of the builder-level async configuration.mailer.testConnection(true)requiresbatch-module, even though async sending already has a built-in fallback.Notes
This came up while triaging #608. The no-arg method blocking is valid for a normal synchronous mailer, but not for a mailer explicitly configured with
.async().