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, <[email protected]> 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 <[email protected]> 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 > > <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
