potiuk commented on PR #73302: URL: https://github.com/apache/airflow/pull/73302#issuecomment-5725273424
Independently reproduced this and landed on the same fix, so here's a second data point on the boundary. Ran the failing test against the published wheels either side of it: | starlette | `test_form_parser_error_keeps_its_own_detail` | |---|---| | 1.3.0 | `assert 422 == 400` | | 1.3.1 | passes | So 1.3.1 is exactly right, not off by one. The mechanism matches the description: through 1.3.0, `Request._get_form` builds `FormParser(headers, stream)` with no limits and no `MultiPartException` -> `HTTPException(400)` translation on the urlencoded branch, while the multipart branch has had both all along. 1.3.1 adds them ([Kludex/starlette#3329](https://github.com/Kludex/starlette/pull/3329)). Two things that might be worth adding to the description, since both bear on how risky the bump is: **It doesn't drag `fastapi` along.** Resolving the two direct constraints on their own with `--resolution lowest-direct` gives `fastapi==0.133.0`, `starlette==1.3.1` — and the failing run resolved `fastapi==0.133.0` with `starlette==1.0.1`, so starlette is the only thing that moves. Worth stating explicitly, since raising a floor that sits under a capped dependency can quietly push the cap. **It narrows the tested range rather than widening it.** `main`'s `uv.lock` already resolves starlette to 1.6.0, so regular CI has been green well above the new floor all along. The bump only stops the nightly job exercising 1.0.1–1.3.0, a range nothing else covers. One note on verification: `core:LowestDeps:14:3.10:API...CLI` — the job that actually failed in [run 35265542917](https://github.com/apache/airflow/actions/runs/35265542917) — is still pending here at time of writing. That's the one to watch before merge. --- Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
