Hi Ash, Agreed. If a TaskGroup is treated as a single unit, a path that leaves the group and comes back into it is a cycle.
I've updated #73746 so that a dependency into or out of any task in a TaskGroup counts as a dependency of the whole group. Thanks! Dheeraj On Tue, Sep 29, 2026 at 12:47 PM Damian Shaw <[email protected]> wrote: > I think most people create these by accidented (or at least I did), so +1 > to this deprecation cycle > > -----Original Message----- > From: Jarek Potiuk <[email protected]> > Sent: Sunday, September 27, 2026 3:43 PM > To: [email protected] > Subject: Re: [LAZY CONSENSUS] Deprecate cyclic TaskGroup dependencies in > 3.4, reject them in 3.5 > > +1 > > On Sun, Sep 27, 2026 at 8:21 PM Blain David <[email protected]> > wrote: > > > > +1 for me, I like the idea. > > > > General (Internal Property) > > ________________________________ > > From: Dheeraj Turaga <[email protected]> > > Sent: Saturday, September 26, 2026 17:23 > > To: [email protected] <[email protected]> > > Subject: Re: [LAZY CONSENSUS] Deprecate cyclic TaskGroup dependencies > > in 3.4, reject them in 3.5 > > > > EXTERNAL MAIL: Indien je de afzender van deze e-mail niet kent en deze > niet vertrouwt, klik niet op een link of open geen bijlages. Bij twijfel, > stuur deze e-mail als bijlage naar [email protected]<mailto: > [email protected]>. > > > > Apologies: > > here's the initial discussion link: > > https://lists.apache.org/thread/sossl7b2w2ftyk4028qrhps2tcdxj2px<https > > ://lists.apache.org/thread/sossl7b2w2ftyk4028qrhps2tcdxj2px> > > > > On Sat, Sep 26, 2026 at 4:44 AM Jarek Potiuk <[email protected]> wrote: > > > > > I think the list link is wrong :( > > > > > > On Sat, Sep 26, 2026 at 7:03 AM Dheeraj Turaga <[email protected]> > wrote: > > > > > > > Hi all, > > > > > > > > Following the discussion [1], I'm calling for lazy consensus on > > > > how we handle Dags whose TaskGroups depend on each other in a > > > > cycle when each group is treated as a single unit (their task > > > > dependencies themselves are acyclic). > > > > > > > > Proposal: > > > > > > > > 1. In 3.4.0, fix the Grid/Graph HTTP 500 for these Dags [2]. We need > this > > > > fix regardless: filtering the Grid or Graph view can create such a > > > > cycle in a Dag that has none. > > > > > > > > 2. Also in 3.4.0, deprecate these Dags [3]. Parsing them issues a > > > > TaskGroupCycleDeprecationWarning and shows a Dag warning in the UI > > > > naming the TaskGroups involved. They keep parsing and running. > > > > > > > > 3. From 3.5.0, reject them at parse time with an import error [4]. As > > > > Jarek suggested, we treat this as a bug fix, since these > dependencies > > > > were never intended to be supported. This is an exception to our > > > > deprecation policy, which would otherwise keep deprecated > behaviour > > > > working until 4.0. > > > > > > > > 4. Scope: only cycles between TaskGroups. Other restrictions on > > > > dependencies into or out of TaskGroups are out of scope and would > need > > > > their own discussion. > > > > > > > > The lazy consensus is open for 72 hours, until Tuesday, 29 > > > > September > > > 2026, > > > > 05:00 UTC. If there are no objections by then, I'll consider it > accepted. > > > > > > > > [1] > > > > https://lists.apache.org/thread/sossl7b2w2ftyk4028qrhps<https://li > > > > sts.apache.org/thread/sossl7b2w2ftyk4028qrhps> > > > > [2] > > > > https://github.com/apache/airflow/pull/73724<https://github.com/ap > > > > ache/airflow/pull/73724> [3] > > > > https://github.com/apache/airflow/pull/73746<https://github.com/ap > > > > ache/airflow/pull/73746> [4] > > > > https://github.com/apache/airflow/pull/73087<https://github.com/ap > > > > ache/airflow/pull/73087> > > > > > > > > Thanks, > > > > Dheeraj > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > ________________________________ > Strike Technologies, LLC (“Strike”) is part of the GTS corporate family. > Strike is a technology solutions provider, and is not a broker or dealer > and does not engage in securities transactions. This communication does not > constitute an offer to sell or the solicitation of an offer to buy any > security in any jurisdiction.. > ________________________________ > > CONFIDENTIALITY / PRIVILEGE NOTICE: This communication and any attachments > are intended solely for the addressee. The information contained in this > communication may be proprietary, privileged, confidential, and/or > protected from unauthorized use or disclosure under applicable law. If you > are not the intended recipient, you are hereby notified that any review, > dissemination, distribution, copying, or other use or disclosure of this > information is strictly prohibited, and may be unlawful. If you have > received this transmission in error, please delete this message and all > copies from your system and notify the sender via return transmittal. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
