Hello everyone. agree with the consensus.
On the naming question, where Jarek said he had no opinion, I'd push for deriving the code from the MRO instead of inventing a separate component taxonomy. Concretely: walk up to AirflowException, strip the "Airflow" prefix and the "Exception" suffix, concat kebab segments root-down. DagNotFoundException(AirflowNotFoundException) -> AERR-NOT-FOUND-DAG TaskInstanceNotFoundException(AirflowNotFoundException)-> AERR-NOT-FOUND-TASK-INSTANCE AirflowTimetableInvalid(AirflowException) -> AERR-TIMETABLE-INVALID The nice side effect is that grouping comes from the class tree for free. except AirflowNotFoundException already catches every AERR-NOT-FOUND-*; you don't need a parallel AERR/SCHED/DAG/NOTFOUND scheme, the Python hierarchy is already doing that work and just becomes visible in the string. btw, Two "extra" things I'd want pinned down before this lands: 1. breaking-change policy when a class gets renamed, since the code mutates with it 2. where the USER_FACING_MESSAGE strings end up the day we want i18n Regards, André Ahlert Em qua., 13 de mai. de 2026 às 09:19, Jarek Potiuk <[email protected]> escreveu: > > What is the benefit of this approach over narrower exception classes? > > > > Let me answer it here and provide more data: > > * Original discussion here: > https://lists.apache.org/thread/k3dxc6lmrwvqgmvjr9x53poswwpoo5o8 (It > started when we had Airflow 3 development in full swing and deferred it to > "after" - I guess this is the "after" :) > * Original issue describing it - with some discussion > https://github.com/apache/airflow/issues/43171 > > Quoting from that issue: > > Goals for this issue are the following: > > > - Identify and revise error messages that are vague, lack context, or do > not provide clear guidance on resolving issues. > - Provide detailed information, context, and actionable steps within the > error messages to help users troubleshoot. > - Transform error messages with meaningful linking wherever possible. > e.g. an error like Celery command failed on host can be transformed or > displayed with something like "Please check your DAG processor timeout > variable for this". So the user has a starting point to start debugging. > > I will let Omar go into more detail, but I think the result of those > discussions was that more precise exceptions with actionable descriptions > can be achieved through more "fine-grained" exceptions, > > This is at least my own recollection of the discussion and its current > state. Or maybe that alone will be enough, Philippe, to answer the > question. > > The discussion happened a long time ago during the Airflow 3 frenzy, so > it's no wonder we all don't remember it. Luckily, our archives remember > everything - this is the great benefit of "if it did not happen on devlist, > it did not happen". > > J. >
