[Vamsi-klu]

Task instance lookup is expected to return exactly one row for a given (dag_id, task_id, run_id, map_index) combination. Today, TaskInstance.get_task_instance can lose that DAG scoping even though its callers already provide dag_id.

That becomes a real scheduler stability problem when two different DAGs use the same run_id, task_id, and map_index. run_id overlap across DAGs is normal because DagRun uniqueness is scoped by dag_id, so values such as manual__... can legitimately appear in more than one DAG. In that case this lookup can match multiple task instances, and the retrieval path fails instead of returning the intended row.

Restoring DAG scoping keeps this helper aligned with the TaskInstance uniqueness key and prevents cross-DAG collisions from turning into scheduler or executor-side lookup failures. All current call sites already pass dag_id, so this also preserves the row they were already intending to fetch.

A regression test covers two DAGs that share the same run_id and task_id and verifies that each lookup returns the task instance for the requested DAG.

closes: #64957

Validation

• breeze run pytest airflow-core/tests/unit/models/test_taskinstance.py::TestTaskInstance::test_get_task_instance_filters_by_dag_id -xvs
• prek run --from-ref main --stage pre-commit
• prek run --from-ref main --stage manual

---

Was generative AI tooling used to co-author this PR?

• Yes — Codex GPT-5

Generated-by: Codex GPT-5 following the guidelines

[Dev-iL]

Why should we not close this PR in favor of #64968, in whose review you yourself participated a short while ago?