potiuk commented on PR #35142: URL: https://github.com/apache/airflow/pull/35142#issuecomment-1776824151
> > Yeah. The list might be a good start. > > Ideally we should provide some copy of DagRun (as well as others) into task context. Something like pydantic models which are use in internal API. But I think we can’t forced r/о context until: > > * AIP-44 completed > * Airflow 3.0 This is actually one of the "soft" mechanism that AIP-44 aims to do. The DagRun | DagRunPydantic in `Context.pyi` is a way how users can check if they are only using the "public" and "static" parts of the dagrun via context. It's been a very bad idea to expose DB objects with some logic via context, but I agree we cannot do much until either AIP-44 or Airflow 3.0 becaue this might be heavily breaking change . BTW. In a way - AIP-44 will be a step towards this compatibility breaking if we decide to exclusively use Pydantic vs. DB object for the future (if any) Airlfow 3.0. When you will enable isolation in AIP-44, it will be "mostly" compatible for existing DAGs / custom operators etc. (that was the goal) but any direct `DB` features will be disallowed, so switching 2.0 -> DB API (possibly with a gradual "soft" mechanism that will allow to migrate dag-by-dag) -> 3.0 is quite a nice migration path. -- 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]
