Fix GoogleBaseAsyncHook initialization to properly call parent init

[OscarLigthart]

Context

After upgrading to 3.1.6, we started seeing the following error in our GKEStartPodOperator execution, running in deferred mode:

AttributeError: 'GKEKubernetesAsyncHook' object has no attribute '_event_polling_fallback'
File "/home/airflow/.local/lib/python3.12/site-packages/airflow/providers/cncf/kubernetes/triggers/pod.py", line 161 in run

File "/home/airflow/.local/lib/python3.12/site-packages/airflow/providers/cncf/kubernetes/triggers/pod.py", line 262 in _wait_for_pod_start

File "/home/airflow/.local/lib/python3.12/site-packages/airflow/providers/cncf/kubernetes/utils/pod_manager.py", line 1018 in watch_pod_events

File "/home/airflow/.local/lib/python3.12/site-packages/airflow/providers/cncf/kubernetes/hooks/kubernetes.py", line 1001 in watch_pod_events

• closes: GKEKubernetesAsyncHook missing _event_polling_fallback attribute #60600

Problem

After some research it looks like it's a result of the addition of the _event_polling_fallback in the AsyncKubernetesHook. This is never initialized in the GKEKubernetesAsyncHook, because the AsyncKubernetesHook init method is never called, due to disruption of the MRO chain.

With the current initialization of GKEKubernetesAsyncHook, the MRO is:

1. GKEKubernetesAsyncHook
2. GoogleBaseAsyncHook -> Doesn't call super().__init__(), so it stops here
3. AsyncKubernetesHook
4. KubernetesHook
5. BaseHook

As stated, the initialization stops after 2 due to a missing super().__init__(). Hence, the _event_polling_fallback method is never added.

Solution

I figured it would be less invasive to explicitly call both init methods. We could also consider adding the super().__init__() call to GoogleBaseAsyncHook. This area is relatively new to me, so I'm very open to discuss this!

Though the latter feels more invasive, it also feels like a more proper solution.

EDIT: latter solution doesn't work as it will pass the gcp_conn_id and impersonation_chain to the BaseHook.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Claude Sonnet 4.5 following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[MaksYermak]

Hello @OscarLigthart, thank you for your PR!
In my opinion the best solution here is adding super().__init__() in the __init__ method to the GoogleBaseAsyncHook. Like this:

    def __init__(self, **kwargs: Any) -> None:
        self.log.info("GoogleBaseAsyncHook init")
        # add default value to gcp_conn_id
        if "gcp_conn_id" not in kwargs:
            kwargs["gcp_conn_id"] = "google_cloud_default"

        self._hook_kwargs = kwargs
        self._sync_hook = None
        super().__init__()

I have checked this solution in my local Breeze environment by running example_kubernetes_engine_async.py system test and it solved the problem and started to correctly resolve MRO. @OscarLigthart WDYT about my solution?

[OscarLigthart]

Hello @OscarLigthart, thank you for your PR! In my opinion the best solution here is adding super().__init__() in the __init__ method to the GoogleBaseAsyncHook. Like this:

    def __init__(self, **kwargs: Any) -> None:
        self.log.info("GoogleBaseAsyncHook init")
        # add default value to gcp_conn_id
        if "gcp_conn_id" not in kwargs:
            kwargs["gcp_conn_id"] = "google_cloud_default"

        self._hook_kwargs = kwargs
        self._sync_hook = None
        super().__init__()

I have checked this solution in my local Breeze environment by running example_kubernetes_engine_async.py system test and it solved the problem and started to correctly resolve MRO. @OscarLigthart WDYT about my solution?

Yeah I think that's a much cleaner solution. I reverted my change that was exactly like this, but passing on the kwargs, leading to issues. I will make this change 👍

[VladaZakharova]

@shahar1 Can you please check the change?

[OscarLigthart]

Thanks for the reviews! Can someone merge this PR? I don't have the rights.