Support Dynamic UI Alerts

[codecae]

UI Alerts are helpful for a variety of reasons, but in the current Airflow 3 implementation, they are strictly static for the entire lifetime of the webserver/api-server. Therefore, updates to UI alerts require code changes and special automation or manual rollouts/restarts when alerts must change.

This change simply updates the get_configs() response to obtain alerts from DASHBOARD_UIALERTS using a list comprehension instead of simply returning the DASHBOARD_UIALERTS list as a constant. This is actually legacy behavior from Airflow 2 that has become more rigid Airflow 3.

This change allows for the ability define DASHBOARD_UIALERTS as an iterator instead of simply a static list, allowing for dynamic updates of UI alerts upon refresh of the dashboard page. Given that a static list acts as a iterator, the existing behavior of DASHBOARD_UIALERTS is not affected.

For example, checkout this code and:

1. Start breeze: breeze start-airflow --python 3.11 --dev-mode
2. Wait for api-server to complete startup.
3. Paste the following into the terminal pane:

bash -c 'pip install fortune-python

mkdir -p /root/airflow/config

cat << EOF > /root/airflow/config/airflow_local_settings.py
from typing import Any, Iterator
from fortune import fortune

from airflow.api_fastapi.common.types import UIAlert

class DynamicAlerts(list):
    def __iter__(self) -> Iterator[Any]:
        _types = ["info","warning","error"]
        return iter([UIAlert(text=fortune(),category=t) for t in _types])

DASHBOARD_UIALERTS = DynamicAlerts()

EOF

touch airflow-core/src/airflow/api_fastapi/main.py'

4. Wait for the api-server to restart completely.
5. Open the UI and refresh the dashboard page multiple times to see the UI Alerts change.

Every refresh should render a new set of fortune outputs at the top of the dashboard page in "info", "warning" and "error" formats.

[pierrejeambrun]

I'm not sure of the use case you are trying to address here.

Also mutating the underlying list after startup would have the same effect.

I don't understand why we should recreate a new list on each config call.

[codecae]

I'm not sure of the use case you are trying to address here.

Also mutating the underlying list after startup would have the same effect.

I don't understand why we should recreate a new list on each config call.

Mutating the list is definitely possible. However, attempts to find a hook that that is invoked at any interval to affect such a mutation can't be found. Such an invocation would need to occur within the api-server process, or require communicating from some other thread. From what I could find, this was the simplest way to create this ability without over-engineering some other new api route, async loop or threaded solution. If you have suggestions, I will happily implement otherwise, provided it has the same outcome. As far as I can tell, mutating this list can only occur with physical code changes and service restarts.

The use cases for such an iteration are numerous. In the case there are transient issues with a production environment, temporary alerts can be provided without requiring additional code merges and service restarts (both of which create the potential for additional risk and delay in alerting). Other cases include informing developers the state of GitOps processing of their merged code (current commit, build progress, etc) as processes are in progress.

I suppose, in my mind, the nature of alerts should be short-lived and transient in nature. Having more runtime control over which alerts are displayed is very helpful in this regard. Also -- we have made use of this functionality in Airflow 2 for years and would love to continue using it in Airflow 3.

[pierrejeambrun]

Maybe add a comment above, to explain that this allows to override the value with an Iterable. Otherwise I'm affreaid someone might remove it.

[codecae]

Maybe add a comment above, to explain that this allows to override the value with an Iterable. Otherwise I'm affreaid someone might remove it.

Will do!

[eladkal]

UI Alerts are helpful for a variety of reasons, but in the current Airflow 3 implementation, they are strictly static for the entire lifetime of the webserver/api-server. Therefore, updates to UI alerts require code changes and special automation or manual rollouts/restarts when alerts must change.

This is very good if we can do that!
It's not just in Airflow 3.

@pierrejeambrun The use case of such capability is for announcing something in large dag author deployments. For example: "We have issues with K8s cluster, task may be delayed no need to contact cluster admins".

@codecae I think this feature needs some explanation in the UI alert docs about how to make it dynamic

airflow/airflow-core/docs/howto/customize-ui.rst

Line 65 in 18690f7

Add custom alert messages on the dashboard

[codecae]

This is very good if we can do that! It's not just in Airflow 3.

Not that it really matters, but in Airflow 2, we've been successful at making them dynamic by subclassing list and implementing an override for __iter__() (as demonstrated in the example). This could be done in a far simpler way, but the example was more representative of the workaround we've used in the past.

airflow/airflow/www/views.py

Line 1070 in d9ed7b9

dashboard_alerts = [

@codecae I think this feature needs some explanation in the UI alert docs about how to make it dynamic

I'll try to come up with some simple doc updates to explain how to implement.

[pierrejeambrun]

Glad to hear that this will serve users, I agree a small piece of documentation would be great!

[phanikumv]

@codecae any chance you can address the docs change soon?

[codecae]

Absolutely!

[codecae]

Documentation updated

[pierrejeambrun]

Looks good to me, we need to fix the CI. And I would also remove the Advanced Dynamic Alert Examples sections. Those super specific and the previous example is enough to understand that we can basically implement whatever we like in here.

[pierrejeambrun]

labeling as bugfix because this was supported in AF2 and we probably don't want to wait for 3.2.0 release to have that behavior back.

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test