> There was an issue a while ago proposing to add more values into the context dict.[1] I responded at the time that the proposed values are already available by accessing 'ti' although it’s unclear whether the internals of the variable (which was a concrete SQLAlchemy model TaskInstance at the time) should be considered public. > Fast forward 11 months, with Task SDK implemented, 'ti' (and other things that used to be SQLAlchemy models, e.g. dag_run) are now only simple data constructs that do not provide any server-side functionalities.
This is really cool and a great achievement. So much better than AIP-44 version of it when we had Pydantic "variants" of those > We should first expand the template documentation to outline what attributes are available on the task instance, and encourage users to use them.[2] Absolutely. that should also be explicitly called out in the https://airflow.apache.org/docs/apache-airflow/stable/public-airflow-interface.html to mention that the whole context is public interface and link to the exact specification of it that is documented, maintained, versioned, and we should make sure that any change to it is reflected in "changelog" - because that will now become linked to particular task-sdk version. Also I think what is worth defining is how this relates to the versions of distributions used. Since task-sdk will be "freely" upgradeable and independent of the Airflow version, we should have some rules describing what to expect there. Are "new fields" we are going to add there going to be connected to "airflow" version or "task_sdk" version. I think we need to agree and document expected behaviour here - not only current snapshot, so that our users know what to expect. Including deprecation patterns. > Furthermore, I am also wondering if we should remove try_number and run_id from the context dict. This is the exact same value as on the task instance, and they stand out a bit as not really necessary. I think that might be a bit early, but I would be very much (as long as we agree on deprecation patterns) to deprecate them now rather than remove (to ease airflow 3 migration) - but then agree on some deprecation rules that we could follow and remove them in not-so-distant future. J. On Tue, Mar 25, 2025 at 10:04 AM Tzu-ping Chung <t...@astronomer.io.invalid> wrote: > Hi all, > > There was an issue a while ago proposing to add more values into the > context dict.[1] I responded at the time that the proposed values are > already available by accessing 'ti' although it’s unclear whether the > internals of the variable (which was a concrete SQLAlchemy model > TaskInstance at the time) should be considered public. > > Fast forward 11 months, with Task SDK implemented, 'ti' (and other things > that used to be SQLAlchemy models, e.g. dag_run) are now only simple data > constructs that do not provide any server-side functionalities. > > We should first expand the template documentation to outline what > attributes are available on the task instance, and encourage users to use > them.[2] > > - dag_id > - run_id > - task_id > - try_number > - map_index > - hostname (not totally sure about this) > > Furthermore, I am also wondering if we should remove try_number and run_id > from the context dict. This is the exact same value as on the task > instance, and they stand out a bit as not really necessary. > > TP > > > [1]: https://github.com/apache/airflow/issues/40958 > [2]: > https://airflow.apache.org/docs/apache-airflow/stable/templates-ref.html > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > For additional commands, e-mail: dev-h...@airflow.apache.org > >
