-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
Make Databricks operators' json
parameter compatible with XComs, Jinja expression values
#35433
Comments
@josh-fell I'm happy to contribute with this one. Can this be assigned to me? |
@thcidale0808 Absolutely! All yours. |
I can confirm that this is still happening at version 2.8.2. I tried to workaround the issue using docker images with previous versions but the error persists. I went back many many versions, at least until version 2.3.0, and the issue persists. |
@thcidale0808 Are you still working on this one? |
I can take this over if @thcidale0808 is not working on it anymore. Could you please assign this to me @josh-fell? |
All yours @boraberke! |
* Revert "Fix named parameters templating in Databricks operators (#40864)" This reverts commit cfe1d53. * Revert "Make Databricks operators' json parameter compatible with XComs, Jinja expression values (#40471)" This reverts commit 4fb2140. This reverts PR #40864 and PR #40471. Previously, PR #40471 was contributed to address issue #35433. However, that contribution gave rise to another issue #40788. Next #40788 was being attempted to be resolved in PR #40864. However, with the second PR, it appears that the previous old issue #35433 has [resurfaced](#40864 (comment)). So, at the moment, the case is that we have 2 PRs on top of the existing implementation eventually having nil effect and the previous issues persists. I believe it is better to revert those 2 PRs, reopen the earlier issue #35433 and peacefully address it by taking the needed time.
* Revert "Fix named parameters templating in Databricks operators (#40864)" This reverts commit cfe1d53ed041ea903292e3789e1a5238db5b5031. * Revert "Make Databricks operators' json parameter compatible with XComs, Jinja expression values (#40471)" This reverts commit 4fb2140f393b6332903fb833151c2ce8a9c66fe2. This reverts PR #40864 and PR #40471. Previously, PR apache/airflow#40471 was contributed to address issue apache/airflow#35433. However, that contribution gave rise to another issue apache/airflow#40788. Next apache/airflow#40788 was being attempted to be resolved in PR #40864. However, with the second PR, it appears that the previous old issue #35433 has [resurfaced](apache/airflow#40864 (comment)). So, at the moment, the case is that we have 2 PRs on top of the existing implementation eventually having nil effect and the previous issues persists. I believe it is better to revert those 2 PRs, reopen the earlier issue #35433 and peacefully address it by taking the needed time. GitOrigin-RevId: 4535e08b862e2b7ff4f2a76de7124983d4efe9db
Body
A few Databricks operators exist which have a
json
parameter that can be a JSON object which contains any number of API parameters. In the constructors of these operators, thejson
value can be added to be other parameters that can be passed to the operator likename
,tags
, etc.Since
json
is a templated field, attempting to modify it in this way will fail/not work as expected if the input arg is a string (e.g. "{{ var.json....}}" or an XComArg (meaning it's an output of a previous task). Template fields are not rendered until just before the execute method is called.To illustrate the point, let's use this example DAG where we define the
json
arg in a previous task and use its output:DAG parsing fails with:
Even if we change the
json
arg assignment to use the classic XCom Jinja template approach (i.e.json = "{{ ti.xcom_pull(task_ids='push_json') }}"
), the DAG fails to parse:It would be best to move modifying json (and generally any template field) to the execute method instead.
Currently this impacts the following operators:
Committer
The text was updated successfully, but these errors were encountered: