Remove logical_date from DAG Run APIs and Functions, transition to run_id as sole identifier for Airflow 3.0

[sunank200]

After renaming execuiton_date to logical_date in 43902 this PR removes the logical_date arguments from functions and APIs that are used to retrieve DAG runs, aligning with the broader changes introduced in Airflow 2.2 and preparing for Airflow 3.0. The functions now use run_id as the sole identifier for DAG runs, simplifying the process and eliminating deprecated behaviour.

Motivation:

In Airflow, execution_date has historically been used to distinguish different DAG run instances. However, the introduction of run_id and the DAG run concept in Airflow 2.2 shifts away from using execution_date as an identifier. Continuing to rely on execution_date introduces limitations, such as the inability to handle multiple DAG runs at the same logical time, especially in cases like TriggerDagRunOperator when dynamic runs are generated.

This PR eliminates these limitations by removing execution_dateand logical_date in favor of run_id.

Key Changes:

1. API and Function Changes:

   • The logical_date arguments have been removed from all public APIs and Python functions related to DAG run lookups.
   • run_id is now the exclusive identifier for DAG runs in these contexts.

2. Database Migration:

   • The unique constraint on execution_date in the database has been dropped, as run_id now ensures the uniqueness of DAG runs as part of #41818

Rationale:

Removing execution_date is necessary to enable more flexible DAG run management. For example, dynamic runs created by TriggerDagRunOperator can now be correctly identified and managed without awkward workarounds as discussed in this doc. This change makes subsequent DAG run lookups easier and more robust, while also simplifying the database schema by removing the unique constraint on execution_date.

How execution_date and logical_date Work

1. Logical date is equivalent to execution date: The two are just different names for the same value.
2. Timetable controls logical date: The logical date can be set to any value, not necessarily tied to the data interval's start or end.
3. Schedules dictate behavior: For value-based schedules (like cron), the logical date is set by the timetable class used.

Additionally, users will still be able to view execution_date for reference, renamed as logical_date, and paired with run_id for clarity in the web UI, making it easier to distinguish between DAG runs.

Testing

• Updated unit tests to reflect the changes.

closes: #42339, #42340 and #42338

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[uranusjr]

Assuming green

[rawwar]

@sunank200 , will there be another PR to remove logical_date from Fastapi endpoints as well?

[sunank200]

@sunank200 , will there be another PR to remove logical_date from Fastapi endpoints as well?

@rawwar I think logical_date would be there to filter as part of FastAPI endpoints. But we solely identify DagRun by run_id.

[uranusjr]

We should remove it if the frontend can work without them.