Skip to content

Secrets with slashed IDs return AirflowNotFoundException #57864

@bmanan7

Description

@bmanan7

Apache Airflow version

3.1.1

If "Other Airflow 2/3 version" selected, which one?

No response

What happened?

In Airflow 3.x the execution API route GET /execution/connections/{conn_id} treats the connection ID as a FastAPI path segment. Conn IDs containing / (e.g., dev-env/project-name) are not URL encoded before the request, so Starlette splits them into multiple segments and returns 404 even though the connection exists.

airflow connections get (CLI) still works because it bypasses the execution API, causing a mismatch between CLI and Task SDK behaviour.

Apart from this one will also getAirflowNotFoundException when the secret value is defined as {"username":"uname@somedomain.com", "password":"****"} however we don't get the error if we define secret value as show below:

{
 "conn_type": "http",
 "login": "uname@somedomain.com",
 "password": "***",
 "host": "https://api.somedomain.com",
 "port": 443,
 "extra": "{\"verify_ssl\": false}"
}

it looks like without conn_type defined it doesn't work in Airflow3?

What you think should happen instead?

  • / in secret name should be accepted.
  • Either conn_type should be marked as compulsory and documentation should be updated to reflect this or airflow should accept a secret without conn_type

How to reproduce

  • Start an Airflow 3.x environment.

  • Inside the scheduler container, create a connection whose ID contains /. Example script:

python3 - <<'PY'
from airflow import settings
from airflow.models.connection import Connection

conn = Connection(conn_id="dev-env/project-name", conn_type="http", host="example.com")
session = settings.Session()
session.merge(conn)
session.commit()
PY
  • Add a DAG with a task that calls BaseHook.get_connection("dev-env/project-name") .

  • Trigger the DAG. The task fails and worker logs show a 404 from GET /execution/connections/dev-env/project-name.

  • (Optional sanity check) Running airflow connections get dev-env/project-name -oyaml still works because it bypasses the execution API.

Operating System

macOS 15.6.1

Versions of Apache Airflow Providers

No response

Deployment

Official Apache Airflow Helm Chart

Deployment details

No response

Anything else?

No response

Are you willing to submit PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:APIAirflow's REST/HTTP APIarea:corekind:bugThis is a clearly a bugneeds-triagelabel for new issues that we didn't triage yet

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions