Remove align param from iter dagrun infos by dstandish · Pull Request #61420 · apache/airflow

dstandish · 2026-02-03T23:22:04Z

I don't think this param does anything. It's only set to False when called from within get_run_ids, within set_state, which is only called when marking tasks as failed. At best it seems it is called in an extremely odd and impossible to understand edge case. But let's see what the tests say.

uranusjr

The argument only matters if start_date is not aligned with the schedule, but in set_state it always is (line 173) so the argument should make no difference. I think this should be fine.

dstandish · 2026-02-04T11:27:01Z

ok so re your comment, re line 173

just thinking it through .... i looked and ....

current logical date would be from the run id you supplied when calling

it appears current_logical_date is a logical date but, does it matter if the run id passed here is a manual run? (in which case the logical date might be not driven by the timetable).

i'm just not sure that it really matters in any circumstance

so the scenario here is like, manual run, and getting the future (or past) runs relative to that manual (non-aligned) run right?

basicallly where the rubber meets the road here is this block

 dates = [
info.logical_date
for info in dag.iter_dagrun_infos_between(start_date, end_date)
if info.logical_date # todo: AIP-76 this will not find anything where logical date is null
]
run_ids = [dr.run_id for dr in DagRun.find(dag_id=dag.dag_id, logical_date=dates, session=session)

am not sure why we even bother to iter the run infos. why do we not just query based on date range

we iter the run infos to identify dates.

then we perform lookup for those specific dates.

why not just query all the runs in the range?

i feel like if we made that change (just query the runs) no one would ever notice or care
and if anyone ever did notice or care, their feelings would probably be positive

dstandish · 2026-02-04T11:51:47Z

so, i decided to go with this which seems it should do basically the same thing

 dates = {current_logical_date}
dates.update(
info.logical_date
for info in dag.iter_dagrun_infos_between(start_date, end_date)
if info.logical_date # todo: AIP-76 this will not find anything where logical date is null
)
run_ids = [dr.run_id for dr in DagRun.find(dag_id=dag.dag_id, logical_date=dates, session=session)]

this feels like it will produce same result.

basically, if the current_logical_date is not aligned, then it would have faked a data interval for that logical date so that it would end up in the dates list, which would then be passed to DagRun.find, so that the run_id passed in originally would be included.

so now i just ensure that no matter what the current logical date ends up included in the dates list, so the passed-in run id will always be included in the output. so i think we're good here.

This is so that it will work for new timetables which implement next_dagrun_info_v2 (which receives DagRunInfo objects instead of data intervals. I also remove logic that is no longer needed and simplify the function. Some of the logic is leftover from when the align parameter was there (removed in #61420). Without it, the logic can be simplified and condensed, e.g. by not getting an initial info before starting the loop.

This param does not appear to be needed. It's only set to False when called from within get_run_ids, within set_state, which is only called when marking tasks as failed etc, and only under certain conditions, when clearing "past" or "future" runs. I think it only would make a difference if the object run was manually triggered thus did not align with the timetable. We can handle that case by just including the object run in the returned run ids.

…1465) This is so that it will work for new timetables which implement next_dagrun_info_v2 (which receives DagRunInfo objects instead of data intervals. I also remove logic that is no longer needed and simplify the function. Some of the logic is leftover from when the align parameter was there (removed in apache#61420). Without it, the logic can be simplified and condensed, e.g. by not getting an initial info before starting the loop.