Skip to content

Remote logging not working in Airflow 3.2.2 #68366

@m8719-github

Description

@m8719-github

Under which category would you file this issue?

Airflow Core

Apache Airflow version

3.2.2

What happened and how to reproduce it?

Following an update to Airflow 3.2.2 logs are no longer being uploaded to remote destinations such as S3.

What you think should happen instead?

Remote logging is working fine in Airflow 3.2.1
Task logs should be uploaded to remote destinations and displayed in UI

Operating System

Linux

Deployment

Other

Apache Airflow Provider(s)

No response

Versions of Apache Airflow Providers

apache-airflow-providers-common-compat==1.15.0
apache-airflow-providers-common-io==1.7.2
apache-airflow-providers-common-sql==2.0.0
apache-airflow-providers-standard==1.13.1
apache-airflow-providers-cncf-kubernetes==10.17.1
apache-airflow-providers-mysql==6.6.0
apache-airflow-providers-databricks==7.15.0
apache-airflow-providers-openlineage==2.17.0
apache-airflow-providers-datadog==3.10.4
apache-airflow-providers-http==6.0.2
apache-airflow-providers-pagerduty==5.2.5
apache-airflow-providers-amazon==9.29.0
apache-airflow-providers-ftp==3.15.0
apache-airflow-providers-sftp==5.8.0
apache-airflow-providers-trino==6.6.0
apache-airflow-providers-cube==1.0.0
apache-airflow-providers-slack==9.10.0
airflow-provider-great-expectations==1.0.0

Official Helm Chart version

Not Applicable

Kubernetes Version

No response

Helm Chart configuration

No response

Docker Image customizations

None

Anything else?

Following warning is logged:

{
  event: Unable to find AWS Connection ID 'aws_default', switching to empty.
  filename: base_aws.py
  level: warning
  lineno: 639
  logger: airflow.task.hooks.airflow.providers.amazon.aws.hooks.s3.S3Hook
  timestamp: 2026-06-09T21:10:22.495664Z
}

The root cause of this issue is the connection preloading behavior on the worker.
Following work done in this PR for Two-token mechanism for task execution, the worker, at the start, now gets a workload scoped long-lived token which does not have access to connections and so the connection preload logic gets None for connections and caches it here.
A potential fix is simple one-liner: do not cache None allowing fall-through logic to hit actual connection get call here. This connection get call will succeed following task execution because the worker token is updated to execution scoped token via the API client's _update_auth() hook once a task is run/started.

Are you willing to submit PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions