Airflow deferrable Kubernetes Job fails without pod logs

An Airflow task that says BackoffLimitExceeded without the container’s output leaves an operator guessing. A current upstream issue reproduces this with KubernetesJobOperator, deferrable=True, wait_until_job_complete=True and get_logs=True. The report says execute_complete raises on the error event before its log-writing block, and cleanup may then remove the pod.

Confirm the operator path

Record Airflow and Kubernetes provider versions and the four relevant operator settings. Reproduce with a disposable Job that prints a known line then exits nonzero. Check whether the line appears in the Airflow task log and whether the Kubernetes pod logs still exist.

Preserve evidence before cleanup

For affected deployments, capture Job and pod logs through Kubernetes observability or adjust the retention/cleanup strategy under your operational policy. Include retry-created pods, which the report says may not be represented in the original deferred event’s pod list.

Verify a fix on failure, not success

A successful Job logging correctly does not validate the failing branch. Test nonzero exits, backoff retries and log-reader errors; ensure the original Job failure remains the reported cause even if retrieving logs also fails.

Adovo’s view

Failure logs are part of the product, not optional decoration. A pipeline that removes the evidence before an operator can read it turns a small container error into a prolonged incident. Keep the failing branch observable.