Skip to content

build(deps): bump fastapi to 0.133.0 and starlette to 1.0.1 - #29084

Closed
yuneng-berri wants to merge 4 commits into
litellm_internal_stagingfrom
litellm_/elastic-chaum-c89630
Closed

build(deps): bump fastapi to 0.133.0 and starlette to 1.0.1#29084
yuneng-berri wants to merge 4 commits into
litellm_internal_stagingfrom
litellm_/elastic-chaum-c89630

Conversation

@yuneng-berri

Copy link
Copy Markdown
Contributor

Summary

  • Bumps fastapi from 0.124.4 to 0.133.0 in the proxy extra. 0.133.0 is the first release that drops the starlette<0.51.0 upper bound.
  • Adds starlette>=1.0.1,<2.0 to the proxy extra. Previously starlette was a free-floating transitive; using a range (rather than ==) avoids narrowing the resolution space for downstream [proxy] adopters that share an env with other ASGI middleware.
  • uv.lock now pins fastapi==0.133.0 and starlette==1.0.1 (lock-level reproducibility for Docker is unchanged).

Test plan

  • make test-unit passes locally
  • CI green

fastapi 0.124.4 capped starlette at <0.51.0, so reaching starlette 1.0.1
requires fastapi >=0.133.0 (the first release that drops the upper bound).

Pin starlette as a range (>=1.0.1,<2.0) rather than ==, since it was
previously a free-floating transitive — keeping it a range avoids
narrowing the resolution space for [proxy] adopters who pip-install
alongside other ASGI middleware. uv.lock still pins to 1.0.1 exactly.
@yuneng-berri
yuneng-berri requested a review from a team May 27, 2026 21:50
@codecov

codecov Bot commented May 27, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@greptile-apps

greptile-apps Bot commented May 27, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR upgrades fastapi from 0.124.4 to 0.133.0 and starlette from 0.50.0 to 1.0.1, lifting starlette to a direct [proxy] dependency with a range constraint. The previously-flagged breaking change from FastAPI 0.132.0 (strict_content_type=True as the new default) is correctly handled by passing strict_content_type=False to the FastAPI() constructor in proxy_server.py.

  • proxy_server.py: Adds strict_content_type=False to preserve existing behavior for clients that omit Content-Type: application/json on JSON-body requests.
  • pyproject.toml: Bumps fastapi to ==0.133.0, adds starlette>=1.0.1,<2.0; the block comment is rewritten to document the range-vs-pin policy.
  • uv.lock: Pins fastapi to 0.133.0, starlette to 1.0.1, and adds typing-inspection as a new transitive dependency of fastapi 0.133.0.

Confidence Score: 5/5

The upgrade is safe to merge: the only behavioral change from FastAPI 0.132.0 (strict content-type enforcement) is explicitly opted out via strict_content_type=False, and no deprecated Starlette 1.0 APIs are in use.

Both fastapi and starlette are version-bumped with lock-file reproducibility intact. The one backwards-incompatible behavior change introduced in the upgrade path is explicitly mitigated in proxy_server.py. No other deprecated or removed APIs from starlette 1.0 are used in the proxy codebase.

No files require special attention.

Important Files Changed

Filename Overview
litellm/proxy/proxy_server.py Adds strict_content_type=False to the FastAPI() constructor to opt out of FastAPI 0.132.0's new default that rejects requests without a Content-Type: application/json header.
pyproject.toml Bumps fastapi to ==0.133.0 and adds starlette>=1.0.1,<2.0 as a direct dependency; block comment updated to explain the range-vs-pin policy.
uv.lock Lock file regenerated: fastapi pinned to 0.133.0, starlette pinned to 1.0.1, typing-inspection added as new transitive dependency, exclude-newer advanced 5 days.

Reviews (2): Last reviewed commit: "Merge remote-tracking branch 'origin/lit..." | Re-trigger Greptile

Comment thread pyproject.toml
"uvloop==0.21.0; sys_platform != 'win32'",
"fastapi==0.124.4",
"fastapi==0.133.0",
"starlette>=1.0.1,<2.0",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 ORJSONResponse is deprecated in FastAPI 0.131.0 and will be noisy in logs

FastAPI 0.131.0 (included in this upgrade) deprecated both ORJSONResponse and UJSONResponse. The proxy imports and uses ORJSONResponse extensively across many endpoint files. It still works in 0.133.0 but will emit deprecation warnings at runtime that may flood logs. Since the project already pins orjson==3.11.6 directly, migrating to returning Response(content=orjson.dumps(data), media_type="application/json") (or switching to JSONResponse) is straightforward and avoids the noise. This doesn't need to block the bump, but it's worth tracking.

…n policy

fastapi 0.132.0 flipped strict_content_type to True by default, which
would start rejecting JSON requests that omit Content-Type:
application/json — a real breakage surface for proxy adopters whose
clients (curl scripts, legacy SDKs, custom integrations) don't always
set the header. Opt out explicitly to keep current behaviour.

Also rewrite the [project.optional-dependencies] comment to match
reality after this PR: uv.lock provides Docker/CI reproducibility,
pyproject constraints guard adopter resolver drift, and ranges are
used when a previously-transitive dep is being lifted to a direct
constraint (e.g. the new starlette entry).
@yuneng-berri

Copy link
Copy Markdown
Contributor Author

@greptile ORJSONResponse - will not do in this PR, will track as a pending item. It is deprecated not removed, so we will deal with some noise for now. This should not block the security patch

@greptile-apps

greptile-apps Bot commented May 27, 2026

Copy link
Copy Markdown
Contributor

Fair enough — the deprecation warning is noise but not a blocker, and handling it properly across all the proxy endpoint files warrants its own focused PR. Agreed this shouldn't hold up the security patch.

@yuneng-berri

Copy link
Copy Markdown
Contributor Author

@greptile re-review please

@yuneng-berri

Copy link
Copy Markdown
Contributor Author

Closed in favor of #29208. Changes have already landed in internal staging

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants