Apply rerun_with_latest_version to TriggerDagRunOperator reruns

Description

rerun_with_latest_version (introduced in #63884) is a 4-tier config hierarchy (explicit > DAG-level > global config > fallback) that controls whether clearing/rerunning a Dag run uses the latest bundle version. It's wired into the UI clear dialogs, the public clear/backfill API endpoints, and the airflow backfill create CLI command.

It is not wired into TriggerDagRunOperator's reset_dag_run=True path. When the operator is invoked with reset_dag_run=True and the target Dag run already exists, the task SDK falls back to client.clear(dag_id, run_id), which hits POST /execution/dag-runs/{dag_id}/{run_id}/clear. That endpoint calls dag.clear(run_id=run_id) with no run_on_latest_version, so global and DAG-level rerun_with_latest_version config has no effect for operator-driven reruns.

Proposal

Wire the existing rerun_with_latest_version hierarchy into the execution-API clear_dag_run endpoint, so TriggerDagRunOperator(reset_dag_run=True) picks up the same global/DAG-level config the UI and public API already honor.

In airflow-core/src/airflow/api_fastapi/execution_api/routes/dag_runs.py, clear_dag_run calls resolve_run_on_latest_version(None, dag_id, session) and forwards the result to dag.clear(run_on_latest_version=...). No payload/schema change; no client change.

Use case

Teams that set rerun_with_latest_version = True globally (or per-DAG) expect operator-driven reruns to behave consistently with UI- and API-driven reruns. Today they don't — a TriggerDagRunOperator(reset_dag_run=True) re-runs on the original bundle version regardless of config.

I'd envisioned not allowing arbitrary bundle version when triggering. If we allow it, I do think it requires a bit more consideration from a security perspective, as you could then kick a run on a version that was never actually seen by Airflow. (e.g. for git, it means you could run with a commit that was never in the tracking branch, allowing you to bypass reviews).

@jedcunningham

@jedcunningham Thanks very much for this! I can certainly remove this aspect from the scope but I was wondering if we could only allow versions that exist in DagBundleModel (versions Airflow has actually seen/refreshed):

e.g.

# In dag_runs.py                                                                                                                                                                                            

if bundle_version and bundle_version != "__LATEST__":
# Validate that this version exists in DagBundleModel                                                                                                                                                   
  dag_bundle = session.scalars(
      select(DagBundleModel).where(DagBundleModel.name == dm.bundle_name)
  ).one_or_none()

  if dag_bundle and dag_bundle.version != bundle_version:
      raise HTTPException(
          status.HTTP_400_BAD_REQUEST,
          detail=f"Bundle version '{bundle_version}' has not been seen by Airflow"
      )

Actually, looking at it in more detail I think eliminating arbitrary bundle versions from this for now would be best and simplifies what I need to do quite a bit!

I think that's a good path forward 👍

Add bundle version parameters for operator, DAG, and global configura…

Add run_on_latest_version parameter at three configuration levels

There's a PR open now that attempts to implement this and #60887. This is the most complicated feature I've attempted to implement and It has raised a lot of reviewers so I'm expecting some comments!

Add run_on_latest_version parameter at three configuration levels

@nathadfield

@nathadfield We are unassigning you from this issue as part of our updated assignment policy.

This is not meant to discourage your contribution — quite the opposite! You are still very welcome to work on this issue and submit a PR for it. Simply comment that you are working on it and open a PR when ready.

We found that formal assignments were not working well, as they often prevented others from contributing when the assignee was not actively working on the issue.

@potiuk

Thanks @potiuk! I am mostly definitely still going to do this.

Apply `rerun_with_latest_version` to TriggerDagRunOperator reruns

Navigation Menu

Repository navigation

Apply `rerun_with_latest_version` to TriggerDagRunOperator reruns #60880

Description

Proposal

Use case

10 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Apply rerun_with_latest_version to TriggerDagRunOperator reruns #60880

Description

Description

Proposal

Use case

Activity

jedcunningham commented on Jan 22, 2026

nathadfield commented on Jan 23, 2026

nathadfield commented on Jan 23, 2026

jedcunningham commented on Jan 23, 2026

10 remaining items

nathadfield commented on Jan 27, 2026

potiuk commented on Mar 2, 2026

nathadfield commented on Mar 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Apply `rerun_with_latest_version` to TriggerDagRunOperator reruns #60880