Under which category would you file this issue?
Task SDK
Apache Airflow version
3.2.2
What happened and how to reproduce it?
Automatic task failure/retry emails sent through the email_on_failure and email_on_retry task options do not honor the SMTP connection extra from_email value.
The SMTP provider's SmtpNotifier supports falling back to the SMTP connection extra from_email when its own from_email argument is None, but the task runner always passes a non-None fallback value from [email] from_email or the hard-coded fallback airflow@airflow. As a result, the SmtpNotifier connection-extra fallback path is never reached for these automatic task error emails.
Steps to reproduce
-
Configure the SMTP provider as the email provider and use an SMTP connection for task email notifications.
-
Configure the SMTP connection extra with a sender address, for example:
{
"conn_type": "smtp",
"extra": {
"from_email": "alerts@example.com"
}
}
-
Do not set [email] from_email.
-
Create a task that uses automatic failure or retry emails, for example:
EmptyOperator(
task_id="failing_task",
email=["operator@example.com"],
email_on_failure=True,
)
-
Make the task fail.
-
Airflow trys to send the email from airflow@airflow
The reason is that task-sdk/src/airflow/sdk/execution_time/task_runner.py constructs the notifier with:
notifier = SmtpNotifier(
to=to_emails,
subject=subject,
html_content=html_content,
from_email=conf.get("email", "from_email", fallback="airflow@airflow"),
)
Since SmtpNotifier.from_email is never None, the following fallback in providers/smtp/src/airflow/providers/smtp/notifications/smtp.py is skipped:
if self.from_email is None:
if smtp.from_email is not None:
self.from_email = smtp.from_email
else:
raise ValueError("You should provide `from_email` or define it in the connection")
fields_to_re_render.append("from_email")
What you think should happen instead?
Automatic task failure/retry emails sent using the SmtpNotifier should use the most specific configuration available.
I would expect the following outcomes based on the different config fields being set.
- No
[email] from_email config set, and from_email extra field set for the SMTP connection config: use from_email from the SMTP connection config (case from Steps to reproduce, not happening)
Other case for completeness reasons
-
No [email] from_email config set, and no from_email extra field set for the SMTP connection config: use the existing fallback airflow@airflow (this is already the case, altough I personally think an error would make more sense)
-
[email] from_email config set, and from_email extra field not set for the SMTP connection config: use the [email] from_email config. (this is already the case)
-
Both [email] from_email and the SMTP connection extra from_email are set: use from_email from the SMTP connection config, because the more specific config should take precedence over the more general config (currently the more general config [email] from email is used)
While it is debatable if all of my expected outcomes make sense, I would argue that the current configuration can cause quite a lot of confusion as it did for me, because:
Operating System
No response
Deployment
None
Apache Airflow Provider(s)
No response
Versions of Apache Airflow Providers
Official Helm Chart version
Not Applicable
Kubernetes Version
No response
Helm Chart configuration
No response
Docker Image customizations
No response
Anything else?
I know that both task options email_on_failure and email_on_retry will be deprecated in Airflow 4 (e.g. see this PR). Nonetheless I thought I should create this issue as Airflow 3 still will be around for quite some time.
Are you willing to submit PR?
Code of Conduct
Under which category would you file this issue?
Task SDK
Apache Airflow version
3.2.2
What happened and how to reproduce it?
Automatic task failure/retry emails sent through the
email_on_failureandemail_on_retrytask options do not honor the SMTP connection extrafrom_emailvalue.The SMTP provider's
SmtpNotifiersupports falling back to the SMTP connection extrafrom_emailwhen its ownfrom_emailargument isNone, but the task runner always passes a non-Nonefallback value from[email] from_emailor the hard-coded fallbackairflow@airflow. As a result, theSmtpNotifierconnection-extra fallback path is never reached for these automatic task error emails.Steps to reproduce
Configure the SMTP provider as the email provider and use an SMTP connection for task email notifications.
Configure the SMTP connection extra with a sender address, for example:
{ "conn_type": "smtp", "extra": { "from_email": "alerts@example.com" } }Do not set
[email] from_email.Create a task that uses automatic failure or retry emails, for example:
Make the task fail.
Airflow trys to send the email from
airflow@airflowThe reason is that
task-sdk/src/airflow/sdk/execution_time/task_runner.pyconstructs the notifier with:Since
SmtpNotifier.from_emailis neverNone, the following fallback inproviders/smtp/src/airflow/providers/smtp/notifications/smtp.pyis skipped:What you think should happen instead?
Automatic task failure/retry emails sent using the
SmtpNotifiershould use the most specific configuration available.I would expect the following outcomes based on the different config fields being set.
[email] from_emailconfig set, andfrom_emailextra field set for the SMTP connection config: usefrom_emailfrom the SMTP connection config (case from Steps to reproduce, not happening)Other case for completeness reasons
No
[email] from_emailconfig set, and nofrom_emailextra field set for the SMTP connection config: use the existing fallbackairflow@airflow(this is already the case, altough I personally think an error would make more sense)[email] from_emailconfig set, andfrom_emailextra field not set for the SMTP connection config: use the[email] from_emailconfig. (this is already the case)Both
[email] from_emailand the SMTP connection extrafrom_emailare set: usefrom_emailfrom the SMTP connection config, because the more specific config should take precedence over the more general config (currently the more general config[email] from emailis used)While it is debatable if all of my expected outcomes make sense, I would argue that the current configuration can cause quite a lot of confusion as it did for me, because:
Airflow 3 uses the
SmtpNotifierfor sending email triggered byemail_on_failureandemail_on_retryThe SMTP provider changelog for 2.0.0 explicitely states:
Operating System
No response
Deployment
None
Apache Airflow Provider(s)
No response
Versions of Apache Airflow Providers
Official Helm Chart version
Not Applicable
Kubernetes Version
No response
Helm Chart configuration
No response
Docker Image customizations
No response
Anything else?
I know that both task options
email_on_failureandemail_on_retrywill be deprecated in Airflow 4 (e.g. see this PR). Nonetheless I thought I should create this issue as Airflow 3 still will be around for quite some time.Are you willing to submit PR?
Code of Conduct