Dynamic DAG Params behaves differently in manually triggered run vs scheduled run. about airflow HOT 3 CLOSED

I believe the difference is mainly that you use a non-constant parameter default. If no configuration is given at trigger point of a DAG run (which is the case of scheduled runs) then the defaults are applied. In case of a triggered run the config dict is used and over-rides the defaults.

If you modify the config dict at point of trigger and remove values then also the default will be used, same like if you trigger on API and do not pass a conf.

Main issue I see is if you have non-constant defaults in parameters that defaults are changing based on time of evaluation. At the moment this is a conceptual thing and I would not rate as this being a bug.

If you need to have constant parameters throughout the run of a DAG and your default parameter values are "volatile" then I propose that you capture the params initially in a python task ans return them as response. Then this is persisted as XCom and you could use the XCom from the first task to make downstream logic constant. Otherwise it would be good to step back from using volatile defaults. If you need a date, then maybe better try using logical date from the DAG run or leave the field w/o a default and calculate the required volatile input based on other constant facts.

from airflow.

Thanks for the feedback. We will be implementing a task to persist the values in XCom as a workaround as it's suggested by you as well.

For scheduled run, instead of re-evaluating the default value of DAG params, wouldn't it make it more consistent if it evaluates the params (to constant values) and proceed with task runs?

from airflow.

Yes, there was a bit of discussion in the community about changing the (previous, you could rate it "legacy") conf that is merged with the later introduced "params" but no decision was made. It might be something that could be made cleaner in an Airflow 3 I assume.

@hussein-awala made an attempt in a PR (see #29174) to clean this up... but somehow it never made it.

In general persisting the params at point of start sounds reasonable but might be treated as a breaking change, I assume a lot of users on the contrary rely on an option to dynamically evaluate. If this behavior is to be changed, at least there would be an option needed to change to previous logic for backwards compatibility.

I'll put the request as a discussion item into a future Airflow 3.0 list.

from airflow.