Thanks Daniel, Let me clarify my concern. When user set setup/teardown he has no idea unique trigger rule is set under the hood. The user also has no idea that trigger rules are even involved. That is not something he sees unless he checks the code of teardown and setup decorators.
This means that users of ShortCircuitOperator will not even know they need to take action (until it wont work as expexted) and they will propbably start as asking questions. I'm not saying this should modify the plan just raising it as a potential source for pitfall. בתאריך יום ב׳, 27 במרץ 2023, 05:50, מאת Daniel Standish <daniel.stand...@astronomer.io.invalid>: > Thanks Elad for the feedback. > > re 1. i don't really see a problem with the trigger rule being public. The > way I see it, it's another trigger rule like any other trigger rule. Every > trigger rule behaves differently, that's true here too. This one happens to > be relied upon for teardown tasks. That said, I don't think I would > necessarily be opposed to making it private. > > re 2, personally I kindof think it's a good thing. My understanding from > your comments is that with ShortCircuitOperator you can set it to skip all > downstream or just skip the direct relatives. To me this seems great cus > it provides a way to either skip everything (including teardowns) or just > the next task (thus potentially allowing teardowns to run). To me this is > another way in which by staying within the existing dependency and trigger > rule paradigm we have more consistent, predictable, and configurable > behavior. E.g. if we were not using normal deps and trigger rules, then > surely someone would have the opposite concern: "i want to use short > circuit operator to just skip all tasks including teardowns" and we might > not be able to grant that wish, or at least not without more development. > When you use an operator like this, you simply need to know what it does > and configure it in a manner appropriate for your use case. >