[Infra] Bump proxy dependencies and raise minimum Python to 3.10

[yuneng-berri]

Relevant issues

Summary

Routine dependency maintenance for the proxy extra, plus a matching bump to the project's minimum supported Python version.

Changes

• Raise requires-python from >=3.9, <3.14 to >=3.10, <3.14. Python 3.9 reached end-of-life in October 2025 and several of the packages being bumped require Python 3.10+. This is the minimum floor raise needed to pick up the dependency updates.
• Bump orjson from 3.10.15 to 3.11.5.
• Bump fastapi-sso from 0.16.0 to 0.19.0. All fastapi_sso symbols used in the codebase (OpenID, DiscoveryDocument, create_provider, GoogleSSO, MicrosoftSSO) still resolve on 0.19.0.
• Bump python-multipart from 0.0.20 to 0.0.26. Releases from 0.0.21 onwards require Python 3.10+, which is why the floor change is bundled in this PR.
• Regenerate uv.lock against the updated requires-python.
• Clean up python_version markers in pyproject.toml that became redundant or unreachable after the floor change: drop >= '3.9' markers (now always true), drop the < '3.10' entries for psycopg, psycopg-binary, Pillow, pyarrow, langchain, lunary, and pylint (now unreachable). Upper-bound markers (< '3.14') and the py3.10-specific lunary==1.4.36 pin are preserved.

Testing

• uv lock — resolves cleanly.
• docker build -f docker/Dockerfile.non_root . — builds end-to-end against Chainguard Wolfi, Prisma Client generated, image exports successfully.
• Inside the built image:
  • orjson==3.11.5, fastapi-sso==0.19.0, python-multipart==0.0.26 installed.
  • All fastapi_sso imports used by the proxy resolve without error.

Type

🚄 Infrastructure

[greptile-apps]

Greptile Summary

This PR raises the minimum Python from 3.9 (EOL) to 3.10 and bumps three proxy dependencies: orjson (3.10.15→3.11.5), fastapi-sso (0.16.0→0.19.0), and python-multipart (0.0.20→0.0.26). Notably, the fastapi-sso bump to 0.19.0 patches a critical OAuth CSRF vulnerability caused by missing state validation (reported by Snyk Security Labs). The pyproject.toml marker cleanup — dropping unreachable < '3.10' entries and always-true >= '3.9' conditions — is thorough and correct.

Confidence Score: 5/5

Safe to merge; all remaining findings are P2 style suggestions.

Well-executed routine maintenance with a meaningful security fix included. The dependency marker cleanup is complete and correct. The only gap is the absence of a Python 3.10 CI job to test at the new floor, which is a non-blocking P2 observation.

.circleci/config.yml — no CI job exercises Python 3.10, the new minimum supported version.

Important Files Changed

Filename	Overview
pyproject.toml	Raises requires-python to >=3.10, bumps orjson→3.11.5, fastapi-sso→0.19.0 (CSRF security fix), python-multipart→0.0.26, and removes now-dead version markers cleanly.
.circleci/config.yml	CI images updated but no job tests at the new minimum supported Python (3.10); all jobs run on 3.11, 3.12, or 3.13.
uv.lock	Lockfile regenerated against updated requires-python and bumped dependencies; no manual review needed.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["requires-python\n≥3.9 → ≥3.10"] --> B["orjson\n3.10.15 → 3.11.5"]
    A --> C["fastapi-sso\n0.16.0 → 0.19.0\n⚠️ OAuth CSRF fix"]
    A --> D["python-multipart\n0.0.20 → 0.0.26\n(requires ≥3.10)"]
    A --> E["Marker cleanup\ndrop dead < 3.10\ndrop always-true ≥ 3.9"]
    B & C & D & E --> F["uv.lock regenerated"]
    F --> G["Docker build verified\norjson + fastapi-sso\nimports confirmed"]

Loading

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

[greptile-apps]

Stale python_version markers now always true

After raising requires-python to >=3.11, every python_version >= '3.9' and python_version >= '3.10' marker in pyproject.toml is unconditionally satisfied and the condition is dead weight. More importantly, several < '3.10' entries in the dev and ci groups are now unreachable and will never install — the alternate versions on those lines are the only ones that will ever resolve.

Unreachable < '3.10' entries (they will never be selected on any supported Python):

• dev: psycopg==3.2.13 and psycopg-binary==3.2.13 (lines 130–133)
• ci: Pillow==11.3.0 (line 171), pyarrow==21.0.0 (line 177), langchain==0.3.27 (line 179), lunary==1.0.36 and lunary==1.4.36; python_version == '3.10' (lines 181–182)

Always-true markers that can be simplified by dropping the condition (examples):

• PyJWT==2.11.0; python_version >= '3.9' (line 46)
• azure-identity with >= '3.9' (lines 52, 65, 162)
• mcp, polars, a2a-sdk with >= '3.10'
• redisvl, semantic-router, aurelio-sdk — the >= '3.9' half of the compound marker is redundant (the < '3.14' upper bound should be kept)

None of these cause a runtime error, but the dead entries add noise to lock resolution and make it harder to reason about what actually gets installed.

[greptile-apps]

Python 3.10 dropped without explicit notice

The floor jumps from >=3.9 to >=3.11, which silently drops Python 3.10 — a version that remains in active CPython support until October 2026. The PR description only calls out 3.9 being EOL. Users running production workloads on 3.10 (a common LTS-like choice for many Linux distros) will hit a hard install block on the next litellm release with no prior deprecation warning. The python-multipart>=0.0.21 constraint only requires 3.10+, so a floor of >=3.10 would cover the library requirement while being a smaller breaking step; >=3.11 is an additional drop that isn't technically required by any bumped dependency.

Rule Used: What: avoid backwards-incompatible changes without... (source)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!