Vamsi-klu commented on PR #69998: URL: https://github.com/apache/airflow/pull/69998#issuecomment-5337966305
@PrakshiGoyal10 @moomindani I caught the latest review and went through the plugin plus the extra-link path. Those two blockers look like the ones that keep this from actually showing up in the Airflow 3 UI, and I wanted to ask if you are both okay with me taking a pass at them on this PR. The repair buttons never render because Airflow 3 only serializes extra links as a name-to-xcom-key map, then the API server rebuilds them as XComOperatorLink. The job-run link already follows that: it sets xcom_key and store_databricks_job_run_link writes the URL during execute. The two repair links do neither, so /links comes back empty and the UI drops the button. The Airflow 3 branches in get_link never run on that path. The other issue is separate. Even if the URL were built at request time, _get_launch_task_id_v3 still calls get_child_by_label, and SerializedTaskGroup does not have that method. That is the member-task case the single-task link is registered on. If that works for both of you, I would persist the repair URLs into XCom at the same point as the job-run link (before wait_for_termination, so a later Databricks failure still leaves a button), resolve the launch task from the group id or the upstream .launch task instead of get_child_by_label, and add the SerializedDagModel.get_dag round-trip test so this class of break cannot come back silently. I can also take the start_time fragility, the unmapped-key warning on repair-all, and the base_url form-action / redirect notes in the same pass if you want those now. I will not open another PR. I can send a patch you can pull, or I can wait if you already have a fix in flight. -- 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]
