-
Notifications
You must be signed in to change notification settings - Fork 14.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to access operator attrs within Jinja context for mapped tasks #24388
Comments
The proposed workaround:
|
The The fix has been included in #26100. Once that’s merged (to main and released in 2.5), I plan to write up a patch to backport the behaviour to 2.4, so |
Thanks for the response. I tried to do it a couple of ways, including this: But I get the following error:
Here is the full operator definition:
|
Unfortunately there’s currently no way to access the resolved value of a mapped operator. |
No way currently. We'll add it in 2.4.1 |
Apache Airflow version
2.3.2 (latest released)
What happened
When attempting to generate mapped SQL tasks using a Jinja-templated query that access operator attributes, an exception like the following is thrown:
jinja2.exceptions.UndefinedError: 'airflow.models.mappedoperator.MappedOperator object' has no attribute '<operator attribute>'
For example, when attempting to map
SQLValueCheckOperator
tasks with respect todatabase
using a query ofSELECT COUNT(*) FROM {{ task.database }}.tbl;
:jinja2.exceptions.UndefinedError: 'airflow.models.mappedoperator.MappedOperator object' has no attribute 'database'
Or, when using
SnowflakeOperator
and mapping viaparameters
of a query likeSELECT * FROM {{ task.parameters.tbl }};
:jinja2.exceptions.UndefinedError: 'airflow.models.mappedoperator.MappedOperator object' has no attribute 'parameters'
What you think should happen instead
When using Jinja-template SQL queries, the attribute that is being using for the mapping should be accessible via
{{ task.<operator attribute> }}
. Executing the same SQL query with classic, non-mapped tasks allows for this operator attr access from thetask
context object.Ideally, the same interface should apply for both non-mapped and mapped tasks. Also with the preference of using
parameters
overparams
in SQL-type operators, having the ability to map overparameters
will help folks move from usingparams
toparameters
.How to reproduce
Consider the following DAG:
SQLValueCheckOperator
tasksThe logs for the "classic_sql_value_check", non-mapped task show the query executing as expected:
[2022-06-11, 02:01:03 UTC] {sql.py:204} INFO - Executing SQL check: SELECT COUNT(*) FROM dev.tbl;
while the mapped "check_row_count" task fails with the following exception:
SnowflakeOperator
tasksSimilarly, the "classic_snowflake_task" non-mapped task is able to execute the SQL query as expected:
[2022-06-11, 02:01:04 UTC] {snowflake.py:324} INFO - Running statement: SELECT * FROM foo;, parameters: {'tbl': 'foo'}
while the mapped "mapped_snowflake_task task fails to execute the query:
Operating System
Debian GNU/Linux 10 (buster)
Versions of Apache Airflow Providers
apache-airflow-providers-snowflake==2.7.0
Deployment
Astronomer
Deployment details
Astronomer Runtime 5.0.3
Anything else
Even though using the
{{ task.<operator attr> }}
method does not work for mapped tasks, there is a workaround. Given theSnowflakeOperator
example from above attempting to execute the query:SELECT * FROM {{ task.parameters.tbl }};
, users can modify the templated query toSELECT * FROM {{ task.mapped_kwargs.parameters[ti.map_index].tbl }};
for successful execution. This workaround isn't very obvious though and requires from solid digging into the new 2.3.0 code.Are you willing to submit PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: