DatabricksWorkflowOperator do not update ACL on workflow reset

[adamgorkaextbi]

Apache Airflow Provider(s)

databricks

Versions of Apache Airflow Providers

apache-airflow-providers-databricks==7.0.0

Apache Airflow version

2.10.4

Operating System

Linux

Deployment

Official Apache Airflow Helm Chart

Deployment details

official Helm Chart

What happened

DatabricksWorkflowOperator do not update ACL on workflow reset, this is done only during creation of workflow (Databricks API 2.0 implementation)
one more call is needed to Databricks API 2.0

What you think should happen instead

DatabricksWorkflowOperator on workflow reset should also update ACL in next api call

How to reproduce

try to modify ACL after creation of workflow

Anything else

Proposed solution:
after this line:

airflow/providers/src/airflow/providers/databricks/operators/databricks_workflow.py

Line 179 in 6cde25f

job_id = self._hook.create_job(job_spec)

add this code:

            if "access_control_list" in job_spec.keys():
                access_control_list = {"access_control_list": job_spec["access_control_list"]}
                self.log.info(
                    "Updating ACL of Databricks workflow job %s with spec %s",
                    self.job_name,
                    json.dumps(access_control_list, indent=2),
                )
                self._hook.update_job_permission(job_id, access_control_list)

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[rawwar]

@adamgorkaextbi , you haven't explained why it needs to update ACL on workflow reset. If you don't update ACL, does it fail? What's the consequence?

[arollet22]

Maybe I can jump in to answer that question. We are also experiencing the same issue. What happens generally is the Airflow dev forgets to set the correct ACL during the first run, faces a permission issue on the Databricks UI and doesn't understand why its updated ACL configuration doesn't fix the problem. (Usually Airflow workflows/jobs are created using Service Principals which do not grant any rights by default to the group / users).
One other use case I can imagine, although not faced yet, is if you were to migrate a workflow ownership to another group.

The consequence is not that the job doesn't run, that works well, but if one task fails then the dev isn't able to check the logs to correct the error.

[rawwar]

@hardeybisey , would you like to work on this?

[hardeybisey]

@hardeybisey , would you like to work on this?

Sure, I will be happy to pick this up. You can assign it to me.