Secrets with slashed IDs return AirflowNotFoundException
- Dominant language
- Python
- Stars
- 46.9k
- Forks
- 17.8k
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 483
Description
### 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 get`AirflowNotFoundException` 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?
- [x] Yes I am willing to submit a PR!
### Code of Conduct
- [x] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
Contributor guide
Research direction
Start by tracing the execution API route GET /execution/connections/{conn_id} and the BaseHook.get_connection("dev-env/project-name") call, then compare them with the working airflow connections get CLI path. Reproduce the slash-containing ID failure and the secret value without conn_type; done means valid slash-containing IDs work through the Task SDK and the expected conn_type behavior is documented or supported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- fastapi, python
- Domain
- api, backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100