SEPURI-SAI-KRISHNA opened a new pull request, #75123:
URL: https://github.com/apache/airflow/pull/75123
Marking one map index of a mapped task with `include_upstream` or
`include_downstream` resolved the relatives of that task instance as bare task
ids. `TaskInstance.ti_selector_condition` turns a bare task id into `task_id IN
(...)` with no map index predicate, so every map index of every relative was
moved to the requested state, including the instances that belong to other
expansions of the same mapped task group.
Clearing the same selection narrows each relative to the map index that
corresponds to it, through `find_relevant_relatives`. Clearing was fixed for
this in #74548; the mark path was not touched and kept the old behaviour.
Reachable from `PATCH
/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/{map_index}` with
`new_state` and `include_downstream` or `include_upstream`, and from the same
actions in the UI.
### Before
A mapped task group `tg` over a two element list, containing `a >> b`, with
every task instance failed. Marking `tg.a` map index 1 as success with
downstream:
```
('make_arg_lists', -1, 'failed')
('tg.a', 0, 'failed')
('tg.a', 1, 'success')
('tg.b', 0, 'success') <- belongs to the other group instance, was not
selected
('tg.b', 1, 'success')
```
At an expansion width of N, N-1 unrelated task instances are recorded as
finished, so work that never ran is reported as successful and the scheduler
does not run it.
### After
```
('make_arg_lists', -1, 'failed')
('tg.a', 0, 'failed')
('tg.a', 1, 'success')
('tg.b', 0, 'failed')
('tg.b', 1, 'success')
```
### Scope
A plain mapped task expanding over another mapped task's output is
unaffected. Each of its instances depends on the whole upstream task,
`_get_relevant_map_indexes` returns `None`, and the bare task id is the correct
selector. The divergence needs genuine index correspondence, which is what a
mapped task group has.
A relative's map indexes can only be derived from one run's expansion, so
the narrowing applies to a selection within a single Dag run. With `past` or
`future` in play more than one run is in scope and every map index is still
selected, which is the limitation the clear endpoint already documents for
itself. A test pins that behaviour.
Resolution goes through `_get_relevant_map_indexes`, so the mark path now
agrees with clearing shape for shape, including where that helper is
approximate: when a relative is expanded again inside the common group, the
helper derives the width of that further expansion from the selected task's own
expansion, so it can reach fewer indexes than belong to the group instance.
Making it exact also changes XCom resolution, which is why it is left alone
here. A test pins the current outcome for that shape, where the instances of
the other group instance are the ones left alone.
### Tests
Run locally with `uv run --project airflow-core pytest`:
- `airflow-core/tests/unit/api/common/test_mark_tasks.py`: 21 passed. Each
of the four new tests fails without the production change it covers.
-
`airflow-core/tests/unit/api_fastapi/core_api/routes/public/test_task_instances.py`:
511 passed.
- `airflow-core/tests/unit/api_fastapi/core_api/routes/ui/test_grid.py`: 89
passed.
- `airflow-core/tests/unit/models/test_dag.py -k "set_task_instance_state or
set_task_group_state or mark"`: 134 passed.
- `prek run --files airflow-core/src/airflow/api/common/mark_tasks.py
airflow-core/tests/unit/api/common/test_mark_tasks.py --stage pre-commit` and
`prek run mypy-airflow-core`: passed.
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes - Claude Code (Opus 5)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
