RobbeSneyders commented on issue #35234:
URL: https://github.com/apache/airflow/issues/35234#issuecomment-1793398241

   > The usage was added in https://github.com/apache/airflow/pull/30596, 
seemingly only to override and improve the default error message.
   > Either revert that change or find another way, preferably without using 
connexion internals.
   
   This was merged into Connexion in 
https://github.com/spec-first/connexion/pull/1761 and is already part of 
Connexion 3.0.0. Thanks for the contribution!
   
   I had a quick look into how Airflow is using Connexion though, and more 
changes will be needed to retain the old behavior since Airflow isn't really 
using the intended Interface.
   
   Connexion 2 used to inject its functionality as decorators on the view 
functions, which were then registered on the underlying Flask app. There were 
multiple issues with this approach, which is why Connexion 3 moved most of its 
functionality to middleware, which is wrapped around the underlying Flask app. 
You can about the design changes in more detail in [this 
blogpost](https://medium.com/p/a5dc17e81ff8#24ba).
   
   In itself, this doesn't lead to any breaking changes if you're using the 
intended interface of Connexion, which is an application (`FlaskApp` or 
`AsyncApp` in Connexion 3). However in #29631, Airflow moved away from this 
intended interface by creating a `FlaskApi` directly and registering its 
internal blueprint on the Flask app directly. This worked in Connexion 2, since 
the `FlaskApi


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to