PrakshiGoyal10 commented on PR #69998: URL: https://github.com/apache/airflow/pull/69998#issuecomment-5393155352
Thanks for the thorough re-review, and for verifying the buttons through the route's own resolution path plus the revert-each-fix tampering — that's a better check than the test alone. Handled the Airflow 2 case you raised. In the pre-3.0 branch of `WorkflowJobRepairSingleTaskLink.get_link`, the `get_launch_task_id` call is now wrapped so the "no launch task in this group" `AirflowException` returns `""` instead of propagating — a standalone Databricks task renders no repair link rather than surfacing a 500 behind the button, matching the graceful degradation the Airflow 3 branch already has. I reproduced the raise for a top-level task first to confirm the path before changing anything. `WorkflowJobRepairAllFailedLink` is untouched since `_CreateDatabricksWorkflowOperator` only exists inside a workflow group. Added an Airflow-2 test that asserts the standalone-task case returns `""`. Provider unit tests pass locally, ruff and mypy clean. @moomindani — I think that closes the last item. PTAL. --- Drafted-by: Claude Code (Opus 4.8); reviewed by @PrakshiGoyal10 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
