potiuk commented on issue #33945: URL: https://github.com/apache/airflow/issues/33945#issuecomment-1704033802
> What about something similar to what was done to ["trigger dag with config"](https://airflow.apache.org/docs/apache-airflow/2.7.0/release_notes.html#the-trigger-ui-form-is-skipped-in-web-ui-if-no-parameters-are-defined-in-a-dag-33351)? A breaking change was introduced but was announced with a newsfragment and an option to "roll back". > Adding things like this to request params could lead to a bloated API cluttered with rarely used features. I personally think it's not worthy. Any solution like that will create user migration problems. Yes. Easy to solve, but I think if we do use those kind of flags. And we are really trading the "cleaner API" with "more options to configure" and "more complex code to handle those options". And I think we should only introduce such option when we REALLY want to drive users into changing their beheaviours for the future (this is what happened with "dag run conf" - we REALLLY, REALLY want to change how users are writing their DAGS and to give the new users impression that Parameters is the only way to go (they will need to dicover the "old ways with dict config only") I personally think having a new option for that is a bit too much and the case of just having a little more descriptive name in "dag run id" is too disruptive and really "cosmetic" - so risking a number of users, opening issues "After upgrading my stuff stopped working" is not worth it. We could take the risk (and handle the issues) with dag_run conf. But this is really small improvement in consistency of naming comparing to harm it can make and number of issues we - maintainers - will have to handle. -- 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]
