Hi all, I am withdrawing AIP-106.
Following the discussion in this thread and comments on the AIP, I explored success thresholds on mapped tasks, as Jarek suggested. I've came into the conclusion that the benefits do not justify the added complexity. Ash questioned why the downstream task could not use all_done and check the results itself, and whether upstream_failed rather than failed justified scheduler changes. I tested an all_done gate task locally - it checked the success count and passed surviving results to both ordinary and mapped consumers. This covered the use cases I was trying to address without scheduler changes. I moved the AIP to the "Abandoned" section on the wiki - if anyone wants to revisit it in the future - you're more than welcome. Thank you to Jarek, Ash, Amogh, Vikram, and Jens for the feedback. Shahar On Tue, Apr 21, 2026 at 2:00 PM Shahar Epstein <[email protected]> wrote: > Hey everyone, > > I'd like to get your feedback on a new AIP proposal: > > AIP-106: Composable Trigger Rules > https://cwiki.apache.org/confluence/x/64wmGQ > <https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-106+Composable+Trigger+Rules> > > tl;dr > > This proposal introduces a composable expression model for trigger rules, > enabling conditions not expressible with the current enum-based system, > while fully preserving existing trigger rules for simple cases. > For example, "All done, at least two succeeded" can be expressed as > TR.expr(done="all", success=">=2"). > > Design Notes/Constraints: > 1. The aggregate form is AND-only by design, to preserve determinism and > keep evaluation predictable. > 2. The composable model complements (rather than replaces) the enum. Some > trigger rules (e.g. ALL_DONE_SETUP_SUCCESS, ONE_DONE, ALWAYS) remain > intentionally out of scope, and enums remain the more readable option for > simple cases. > > I'd appreciate your feedback on: > > - > > Backward compatibility with existing trigger rules (see Appendix A) > - > > Semantics of eager vs complete evaluation > - > > Scope and limits of the expression model > - > > Potential edge cases and performance implications > - > > UI/observability considerations for debugging expressions > - Anything else > > > Thank you! > > > Shahar >
