codecae commented on PR #54677: URL: https://github.com/apache/airflow/pull/54677#issuecomment-3211538992
> 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. -- 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]
