rusackas commented on code in PR #43903:
URL: https://github.com/apache/superset/pull/43903#discussion_r3939850310
##########
docs/admin_docs/configuration/alerts-reports.mdx:
##########
@@ -472,6 +472,58 @@ ALERT_REPORTS_ENABLE_LINK_REDIRECT = False
The feature uses `WEBDRIVER_BASEURL_USER_FRIENDLY` (or `WEBDRIVER_BASEURL`)
to determine which hosts are internal.
+## Retry on Failure
+
+This feature is gated behind the `ALERT_REPORTS_RETRY` feature flag, which is
+disabled by default:
+
+```python
+FEATURE_FLAGS = {
+ "ALERT_REPORTS_RETRY": True,
+}
+```
+
+With the flag enabled, reports (not alerts) can be configured to
+automatically retry when delivery fails — for example a transient SMTP or
+Slack error — instead of moving straight to an `Error` state. This is
+configured per report in the **Error Handling** section of the report modal:
Review Comment:
Good catch, updated it to say retries cover rendering/export failures too,
not just delivery, since the retry handler wraps the whole `send()` call.
##########
docs/admin_docs/configuration/alerts-reports.mdx:
##########
@@ -472,6 +472,58 @@ ALERT_REPORTS_ENABLE_LINK_REDIRECT = False
The feature uses `WEBDRIVER_BASEURL_USER_FRIENDLY` (or `WEBDRIVER_BASEURL`)
to determine which hosts are internal.
+## Retry on Failure
+
+This feature is gated behind the `ALERT_REPORTS_RETRY` feature flag, which is
+disabled by default:
+
+```python
+FEATURE_FLAGS = {
+ "ALERT_REPORTS_RETRY": True,
+}
+```
+
+With the flag enabled, reports (not alerts) can be configured to
+automatically retry when delivery fails — for example a transient SMTP or
+Slack error — instead of moving straight to an `Error` state. This is
+configured per report in the **Error Handling** section of the report modal:
+
+- **Enable Retries** – turn on automatic retries for this report.
+- **Maximum Retry Attempts** – how many times to retry before giving up (1–10,
default 3).
+- **Send Failed Reports** – send a final failure notification to the report's
recipients once all retries fail (default off).
+- **Failure Notifications** – choose whether **Owners** and/or **Report
Recipients** get a notification after a failed retry attempt (not the initial
failure). Owners are notified by email; report recipients are notified on their
configured channel (email, Slack, etc).
+
+While a retry is pending, the report's status shows as **Retrying**
+(`RETRYING` in `ReportState`) rather than `Error`. Each retry uses
+exponential backoff — the delay doubles after every attempt, up to a
+configurable cap:
+
+```python
+# Delay before the first retry, in seconds. Each subsequent retry doubles
+# this value, up to ALERT_REPORTS_RETRY_MAX_DELAY_SECONDS.
+ALERT_REPORTS_RETRY_BASE_DELAY_SECONDS = 60
+
+# Maximum delay between retries, in seconds.
+ALERT_REPORTS_RETRY_MAX_DELAY_SECONDS = 3600
Review Comment:
Fair point, the code doesn't validate these today. Added a note that they
should stay positive with the max at or above the base delay to get the
advertised backoff.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
