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 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:
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().