-
Notifications
You must be signed in to change notification settings - Fork 14.8k
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
DatabricksRunNowOperator failing as named parameters Jinja templating not getting resolved #40788
Comments
Looks like its related to #40471 |
cc @boraberke |
Hi @vatsrahul1001,
A workaround for this could be setting json parameter as
instead of specifying explicit
I do not have test environment for Databricks to test if my assumption works. Let me know if this fixes the problem. |
Previously, before 6.7.0, even though the named parameters were not templated, they were placed in a templated field named json in the init function. When execute is called, the template field json is resolved. In 6.7.0, the change made it so that the named parameters are saved to a non-templated field overridden_json_params to be later used in the execute function in via calling _setup_and_validate_json. This means that named parameters that would have been templated are no longer resolved. @boraberke Was this an intended change? |
I tried using templating json param as expected, however, existing example DAG using named param with templating should not break by this new change. As mentioned here using only named params instead of json is very common in use. |
#40471 intended to solve the issue #35433, which is to fix This affected all of the below operators:
I agree @vatsrahul1001, apparently docs mentioned some of the params, including Adding necessary named params into Additionally, @potiuk should we revert #40471 or add a new commit that fixes this issue? |
@boraberke As per documentation |
Hello, |
@boraberke are you working on a fix? |
This PR fixes the many named parameters that was templated and was broken with apache#40471. The following operators are affected: DatabricksCreateJobsOperator DatabricksSubmitRunOperator DatabricksRunNowOperator closes: apache#40788
* 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
Apache Airflow version
main (development)
If "Other Airflow 2 version" selected, which one?
No response
What happened?
DatabricksRunNowOperator started failing after upgrading to
6.7.0
version with the below errorI have verified it works well with 6.6.0 version
What you think should happen instead?
No response
How to reproduce
import json
import os
from datetime import timedelta
from typing import Dict, Optional
from airflow.models.dag import DAG
from airflow.utils.timezone import datetime
from airflow.providers.databricks.operators.databricks import (
DatabricksRunNowOperator,
DatabricksSubmitRunOperator,
)
Operating System
Linux
Versions of Apache Airflow Providers
databricks 6.7.0
Deployment
Astronomer
Deployment details
No response
Anything else?
No response
Are you willing to submit PR?
Code of Conduct
The text was updated successfully, but these errors were encountered: