Also was a bit focussing on other stuff, late to the party.
For deprecation we should consider RUFF rules as well.
But on side of code changes I fear a lot of people wil have
implementations based on AirflowException. I did not get the idea of
backwards compatability. If we change Exception types then Operators
implemented on top of Standard-Provider might fail if the receive
different exceptions from inherited classes?
Jens
On 01.09.25 17:05, Buğra Öztürk wrote:
Great discussion! Joining delayed. We have this usage in airflowctl too
where AirflowException is the main one even though it isn't imported from
core.
I agree with the consensus. Great idea to make it backward compatible.
Maybe would be good to define a migration calendar roughly.
While we should prevent usage with some pre-commit hooks, we should also
document the practices we should follow on exception handling for these
changes.
Even though we can manage to migrate seamlessly for the user, I think we
still should warn them about the exception handling usage and give some
kind of deprecation warning if possible
Bugra Ozturk
On Mon, 1 Sept 2025, 16:04 Wei Lee, <weilee...@gmail.com> wrote:
Thanks everyone for joining the discussion!
I think we have some consensus. These should at least apply to new code.
1. Don’t use AirflowException
2. Use Python native whenever possible
3. Create customized exceptions instead of AirflowException
But we’re worried about how and whether we should remove AirflowException.
What I am thinking is removing `raise AirflowException`.
As for AirflowException itself, it looks somewhat challenging.
What if we do something like `CustomException(AirflowException)`,
so `except AirflowException` blocks still work, but we can gain the
benefit of making it descriptive.
Best,
Wei
On Aug 30, 2025, at 11:08 PM, Jarek Potiuk <ja...@potiuk.com> wrote:
I would say we should only worry about backcompat when there's something
to
worry about.
I think Daniel is quite right. In this case what **would** happen if
someone relies on `try AirflowException`, the issue would be immediate to
see and easy to fix (and we can describe it in release notes as
significant
news. I can't easily think of a "reasonable" case where behaviour would
be
changed without crashing. I think that would be a blocker if we can have
a
reasonable way of using it that might change the behaviour in a way that
is
difficult to notice by the user, but when I think of potential cases I
cannot imagine usage that could lead to it.
J
On Wed, Aug 27, 2025 at 3:31 PM Daniel Standish
<daniel.stand...@astronomer.io.invalid> wrote:
Generally agree with this.
I would say we should only worry about backcompat when there's
something to
worry about.
Like, if there's just a remote possibility that a user is doing
something
weird (e.g. in some subclass they wrote of something) then, not really
for
us to worry about. Seems rather internal behavior generally.
If we *know* for sure changing it will break airflow for certain
combinations that should work, that's something to address.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org
