It was closed as it had "closes: #" - and the issue has been closed automatically after merge - not an AI tooling (I missed that one when merging it). The AI tooling never closes issues automatically.
I already opened https://github.com/apache/airflow/pull/69877 drafted to address precisely that issue: adding common.compat LegacyEmailBackendNotifier that wraps the original email_backend (I am **just** re-reviewing it). Maybe you can take a look? J. On Mon, Jul 20, 2026 at 12:14 PM Amogh Desai <[email protected]> wrote: > Hello Eugene, > > Replying as the author of: https://github.com/apache/airflow/pull/57354. > > For context, PR: https://github.com/apache/airflow/pull/57354 rewrote the > email sending helper to construct SmtpNotifier directly, > instead of going through the utils module. That function is what > previously read [email]email_backend and dispatched to whatever > the backend was configured. > > There was a PR shortly after: #65072 which fixed the email_conn_id half > of #65012 but the issue was closed without the email_backend > half being addressed (likely part of the AI triage tool - @Jarek Potiuk > <[email protected]> worth tweaking some instructions there). That was an > oversight, not a > decision and nothing in the operator deprecation warnings or docs says > custom email_backends stop working. So to answer your question > directly: unintentional, not a documented breaking change. > > I plan to take a look in the email sending helper, and if a deployment has > explicitly customized email_backend, restore the old send_email() dispatch > for backward compatibility. > > I will get to it shortly. > > Thanks & Regards, > Amogh Desai > > > On Mon, Jul 20, 2026 at 2:54 PM Eugen Kosteev <[email protected]> wrote: > >> Hi. >> >> *tl;dr* In Airflow 3.2 a breaking change introduced with >> [email]email_backend no longer respected. >> Github issue: https://github.com/apache/airflow/issues/65012 (closed, but >> it wasn't resolved) >> >> [email]email_backend Airflow configuration property should be one of the >> most usable properties in Airflow 2 (prior to Airflow 3), >> and it is likely not all (most of) Airflow users didn't yet migrate to >> SmtpNotifiers in Airflow 3.1 (since there was backward compatibility >> maintained). >> >> What is the community's stance on this? Was this breaking change (in minor >> Airflow version) introduced accidentally? >> If this was intended breaking change, should we then at least have a note >> about it in Release Notes for Airflow 3.2.0 (currently there is no >> mentioning of this)? >> >> https://airflow.apache.org/docs/apache-airflow/stable/release_notes.html#airflow-3-2-0-2026-04-07 >> >> >> *Background:* >> In Airflow 3.0 email/email_on_retry/email_on_retry task parameters were >> deprecated (in favor of SmtpNotifier(s)), >> DAGs using these parameters will have warning messages but still continue >> to work using [email]email_backend and >> [email]email_conn_id Airflow configuration properties to send emails: >> >> https://github.com/apache/airflow/blob/3.0.6/task-sdk/src/airflow/sdk/bases/operator.py#L1048 >> >> https://github.com/apache/airflow/blob/3.0.6/task-sdk/src/airflow/sdk/execution_time/task_runner.py#L1157 >> >> https://github.com/apache/airflow/blob/3.0.6/airflow-core/src/airflow/utils/email.py#L72 >> >> Since Airflow 3.2.0, mails on email_on_retry and email_on_failure are >> sent using >> SmtpNotifier, bypassing the configured email_backend (and email_conn_id - >> this was fixed later). >> >> https://github.com/apache/airflow/blob/3.2.0/task-sdk/src/airflow/sdk/execution_time/task_runner.py#L1612 >> https://github.com/apache/airflow/pull/65072 >> >> There was an open issue https://github.com/apache/airflow/issues/65012 >> about >> this, and it was closed with partial fix "fix stmp email callback to use >> email_conn_id". >> Overall this change - stop respecting [email]email_backend in >> email_on_retry/email_on_retry, forces Airflow users to update their Dags >> to >> use on_*_callback(s) before migrating. >> >> -- >> Eugene >> >
