Deprecate cyclic TaskGroup dependencies

[dheerajturaga]

Dags whose TaskGroups depend on each other in a cycle, when each group is treated as a single unit, parse and run today even though planned TaskGroup features need an unambiguous order between groups. Following the dev list discussion, this deprecates them: they keep working, users are warned now, and Airflow 3.5 is planned to reject them at parse time. This replaces the immediate parse-time rejection proposed in #73087.

Treating a group as a single unit means a dependency into or out of any of its tasks counts as a dependency of the whole group. This covers sibling groups that depend on each other in both directions, and a path that leaves a TaskGroup and comes back into it, even when the tasks inside the group are also ordered directly:

with TaskGroup("group"):
    a = EmptyOperator(task_id="a")
    b = EmptyOperator(task_id="b")
    a >> b

a >> EmptyOperator(task_id="bridge") >> b  # group -> bridge -> group

To remove the cycle, move bridge into the group, or b out of it.

Parsing a Dag with such a cycle now:

• issues a TaskGroupCycleDeprecationWarning from DAG.check_cycle(), so CI can catch it, for example with pytest -W error::airflow.sdk.exceptions.TaskGroupCycleDeprecationWarning;
• records a new task group cycle Dag warning, shown in the UI's Dag warnings and returned by GET /api/v2/dagWarnings.

The message names only the tasks and TaskGroups on the cycle:

Dag 'etl': group1 and group2 depend on each other in a cycle. Cyclic TaskGroup dependencies are deprecated and will fail Dag parsing in Airflow 3.5. See "Cyclic TaskGroup dependencies" in the docs.

The Grid/Graph HTTP 500 for these Dags is fixed separately in #73724. The parse-time rejection in 3.5 is tracked in #73678.

related: #73678
Discussion: https://lists.apache.org/thread/sossl7b2w2ftyk4028qrhps2tcdxj2px
Lazy consensus: https://lists.apache.org/thread/b6h120jw7tv1l1zf1ovwrok2zk4hyvwc

---

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

• Yes — Claude Code (Opus 5.5)

Generated-by: Claude Code (Opus 5.5) following the guidelines

[dheerajturaga]

@bbovenzi would like your thoughts on the UI, would like to get this in 3.4 as agreed in Lazy consensus https://lists.apache.org/thread/5fpwlxg4y6jhyrw7n2m3jz3o7t6xvhlk

cc: @ashb

[bbovenzi]

Makes sense to me UI-wise. I am working on improving our warning banner UX but having another category doesn't get in the way of that

[kaxil]

LGTM, thanks. Feel free to ignore these:

• test_dag_topological_sort_task_group_cycle builds the a >> bridge >> b shape and calls dag.check_cycle() bare, so it now emits TaskGroupCycleDeprecationWarning without asserting it, and the docstring's "although check_cycle passes" is out of date. Wrapping the call in pytest.warns(TaskGroupCycleDeprecationWarning) would make that explicit.
• The function-body from airflow.sdk import TriggerRule in test_dag_add_task_checks_trigger_rule is redundant now that TriggerRule is in the module-level imports.