Hi Omkar, What is the benefit of this approach over narrower exception classes?
Best regards, *✨ **Philippe Gagnon* *Meet for 30 mins 📅* <https://calendar.app.google/5qzgD9SadybUvSCv8> On Mon, May 11, 2026 at 5:14 AM Omkar P <[email protected]> wrote: > Hi team, > > Starting this thread to discuss the design of Airflow error codes. These > are LLM-friendly strings starting with AERR, which airflow devs can use > when raising exceptions, to convey the error context to dag users in a > succinct way. Providing current design details below. > > PR: https://github.com/apache/airflow/pull/65423 > > Feature flow: > 1. airflow dev identifies error case and defines a new error code in the > error mapping yaml (say AERR002). > 2. dev then adds AirflowErrorCodeMixin to respective exception class > that they'd want to raise with an error_code. > 3. dev then specifies the error_code in raise in code (e.g. raise > AirflowNotFoundException(..., error_code="AERR002")). > 4. dev runs breeze build-docs that generates a new docs page AERR002.rst > 5. breeze static check takes care of validating if error code is mapped > to correct exception class. > > User side: > On airflow users' side, they now see airflow error code as > part of the stack trace, which they can use for communicating problems > instead of pasting verbose stack traces. Error codes also improve > LLM-based discovery of airflow errors as codes are much more > deterministic/well-defined than plain stack traces. > > Open questions: > 1. Should the error code be mandatory for all raises of an exception > class that uses them? > 2. Where should the error code info be stored? Is a YAML-based registry > good enough? > 3. Shall we have a 1:1 mapping between an error code and exception > class? e.g. AirflowNotFoundException mapped only to AERR002 i.e. only one > error code. (current implementation in PR has supports many to one mapping, > one exception class <-> multiple error codes based on respective context). > > Look forward to your thoughts on above open questions or any other > design suggestions you'd like to add, thanks! > > Regards, > Omkar >
