Forum Discussion
Intermittent CeleryExecutor state mismatches and missing task logs in Fabric Airflow
Based on your description, this sounds more like an infrastructure or executor synchronization issue than a problem with your DAG or KubernetesPodOperator implementation.
A few thoughts on your questions:
1. Queued → Failed state mismatch
This can occur if the Celery worker, scheduler, or broker loses synchronization. For example, if a worker crashes, loses broker connectivity, or times out before acknowledging the task, the executor may report the task as failed while the scheduler still considers it queued until reconciliation occurs.
2. Blank hostname in the log URL
A missing hostname typically suggests the task never reached a healthy worker, or the worker exited before its metadata was registered. Since the log URL has no host, it appears the log-serving endpoint was never successfully associated with that task attempt.
3. Additional diagnostics
Unfortunately, Fabric's managed Airflow environment doesn't expose all of the underlying Celery, broker, or Kubernetes infrastructure logs that you would have access to in a self-managed deployment. If both the Airflow task logs and Fabric Cluster Logs are empty during the incident, there may be little additional telemetry available from the user side. It would be useful to correlate:
Airflow scheduler logs around the failure time.
Workspace capacity health or service incidents.
Whether multiple unrelated DAGs experienced similar behavior at the same time.
4. KubernetesPodOperator
KubernetesPodOperator is supported, but the behavior you're seeing doesn't point to the operator itself, especially since it affects both Fabric-managed Kubernetes and an external AKS cluster. That suggests the issue is occurring before pod creation or task dispatch rather than within the Kubernetes workloads.
Since the failures are intermittent, affect multiple unrelated tasks simultaneously, produce invalid log URLs, and leave no cluster logs, I'd recommend opening a Microsoft support ticket. Include the DAG run IDs, timestamps, workspace/region, and evidence that retries succeed while initial attempts fail. That should help Microsoft determine whether there was a transient issue with the managed Celery workers, scheduler, broker, or Fabric infrastructure during those execution windows.