[v3-3-test] Restore pluggable email backend for task failure and retry alerts (#69877)#70129
Merged
Conversation
…y alerts (#69877) Since #57354, task email_on_failure / email_on_retry alerts were routed unconditionally through SmtpNotifier, silently ignoring the [email] email_backend configuration. Custom backends (SES, SendGrid, org-internal) stopped delivering failure/retry emails even though the deprecated email_on_* parameters still worked. This restores the old behaviour using the existing [email] email_backend option -- no new configuration is introduced: - A non-default [email] email_backend is transparently wrapped in a new LegacyEmailBackendNotifier, so existing SES / SendGrid / custom backends keep delivering alerts unchanged. The backend is resolved from config at notify time, so the Task SDK keeps no static dependency on airflow.utils.email. - Otherwise the default SmtpNotifier is used, exactly as before. The notifier lives in the Task SDK (airflow.sdk.execution_time.email_backend) next to its only caller, so no extra provider needs to be installed for a custom email backend to keep working. Both failure-email entry points (the worker task-runner path and the DAG-processor callback path) funnel through the same function, so the selected backend is used consistently regardless of how the task failed. The deprecated email_on_* parameters are not un-deprecated; this only keeps their existing behaviour pluggable until removal in Airflow 4. (cherry picked from commit f7dec02) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
1 task
potiuk
marked this pull request as ready for review
July 20, 2026 15:39
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Since #57354, task email_on_failure / email_on_retry alerts were routed
unconditionally through SmtpNotifier, silently ignoring the
[email] email_backend configuration. Custom backends (SES, SendGrid,
org-internal) stopped delivering failure/retry emails even though the
deprecated email_on_* parameters still worked.
This restores the old behaviour using the existing [email] email_backend
option -- no new configuration is introduced:
LegacyEmailBackendNotifier, so existing SES / SendGrid / custom backends
keep delivering alerts unchanged. The backend is resolved from config at
notify time, so the Task SDK keeps no static dependency on
airflow.utils.email.
The notifier lives in the Task SDK (airflow.sdk.execution_time.email_backend)
next to its only caller, so no extra provider needs to be installed for a
custom email backend to keep working.
Both failure-email entry points (the worker task-runner path and the
DAG-processor callback path) funnel through the same function, so the
selected backend is used consistently regardless of how the task failed.
The deprecated email_on_* parameters are not un-deprecated; this only keeps
their existing behaviour pluggable until removal in Airflow 4.
(cherry picked from commit f7dec02)
Co-authored-by: Jarek Potiuk jarek@potiuk.com