ColtenOuO opened a new pull request, #72294:
URL: https://github.com/apache/airflow/pull/72294
### Sumarry
`test_get_task_states_with_task_group_id_and_task_id` in
`airflow-core/tests/unit/api_fastapi/execution_api/versions/head/test_task_instances.py`
(`TestGetTaskStates`) is named to cover the case where `GET
/execution/task-instances/states` is called with both `task_group_id` and
`task_ids` set — the union-of-both-filters branch in `get_task_instance_states`
(`airflow-core/src/airflow/api_fastapi/execution_api/routes/task_instances.py`):
```python
if task_group_id:
group_task_ids = _get_group_task_ids(dag_id, task_group_id, session,
dag_bag)
effective_task_ids = set(task_ids) | group_task_ids if task_ids else
group_task_ids
query = query.where(TI.task_id.in_(effective_task_ids))
```
The request built by the test only ever set `task_group_id` in `params`;
`task_ids` was never passed. That makes the test identical in coverage to
`test_get_task_states_group_id_basic` (which also only exercises
`task_group_id` alone) -- the `task_group_id | task_ids` union branch was
untested despite the test's name claiming otherwise.
### Change
- `test_get_task_states_with_task_group_id_and_task_id`: added `"task_ids":
["task2"]` to the request params, alongside `task_group_id="group1"`. `task2`
is a Dag-level task outside `group1` in this test's Dag, and the fixture
already assigns it a distinct state (`FAILED`), so the expected response now
asserts both `group1.task1` (from the task group) and `task2` (from the
explicit `task_ids` filter) appear together in `task_states` -- actually
exercising the union path the test name describes.
--
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]
