Not that I am unhappy :). I just think it's quite a bit ambiguous to treat "success" and "pretending success" without some indication. But I won't oppose it if others also want this.
This is not a strong "no". Eventually it is more the question to the users that might or might not get confused. It's more "why skipped is not enough". Is this possible to see some real cases that cannot be done with "skip" and existing rules Hongyi? J. On Wed, Feb 16, 2022 at 12:04 AM Daniel Standish <[email protected]> wrote: > > Thinking more, equivalently, when raising AirflowSkipException, we could > optionally include a payload, which would determine the "final" task state. > > I suppose neither of those would really make Jarek happier because for both > of these the final state doesn't convey whether it did work or not. > > What you are suggesting -- a new state -- actually does seem to address that > concern. You are suggesting that we add an entirely new state, which would be > rendered in a different way and therefore would be distinguishable from both > success and skipped. > > But personally I think I'd probably rather see us add an > AirflowSucessException and if you want to do that (with the resulting > ambiguity pointed out by Jarek) then that's up to you. Because it's very > simple and it achieves your main goal. > > My concern with more states is that we already have too many states (note how > much horizontal space they take up on the UI) and they are muddled and > overlapping (IMO they want to be split into different categories) and the > goal can be achieved without a new one.
