Summary

I reviewed the most recent framework-affecting upstream changes visible around FastAPI 0.135.2. The main substantive change in the inspected window is PR #15139:

• Increase lower bound to pydantic >= 2.9.0
• Adjust tests to accept multiple schema shapes across Pydantic 2.9/2.10/2.11

Overall, the code delta is small, but the compatibility impact is not. The main concern is release-management and contract clarity, not request-path performance.

Findings

High — Potential breaking change shipped as a patch release

FastAPI changed its dependency floor from pydantic>=2.7.0 to pydantic>=2.9.0 in what appears as a patch release (0.135.2).

Why this matters

• Patch upgrades are commonly assumed to be safe.
• This can break downstream environments pinned to Pydantic 2.7.x or 2.8.x.
• Lockfile resolution may now force broader upgrades than users expect.

Recommendation

• Treat this as a breaking compatibility note in release notes, or
• Move dependency floor changes like this to a minor release unless there is a hard runtime correctness reason.

Medium — Test contract is now more permissive, reducing schema-surface precision

The updated tests use flexible assertions (IsOneOf) to accept multiple OpenAPI/JSON Schema shapes depending on the installed Pydantic version.

Examples include:

• top-level schema presence/absence differences
• additionalProperties presence differences
• const-only vs const + enum output differences

Why this matters
Generated schema is part of FastAPI's effective public contract. More permissive tests reduce spurious failures, but they also make it easier for accidental schema drift to pass unnoticed.

Recommendation

• Keep compatibility tests flexible where needed.
• Add invariant tests for FastAPI-owned guarantees, e.g. discriminator behavior, required fields, ref stability, and documented normalization behavior.

Medium — Version-floor bump appears driven by compatibility/test variance more than visible runtime framework changes

In the inspected diff, the substantive changes are dependency metadata and tests. I did not find corresponding FastAPI runtime implementation changes in fastapi/ explaining why >=2.9.0 is strictly required.

Why this matters
If older supported Pydantic v2 versions still work at runtime, narrowing the support range increases upgrade friction without clear user benefit.

Recommendation

• Document the exact runtime reason >=2.9.0 is required.
• If the issue is mainly schema-output variance in tests, prefer encoding that in tests rather than constraining all downstream users.

Low — No notable FastAPI-side performance risk in the inspected change

The recent diff does not introduce meaningful new work in request handling, dependency injection, routing, or serialization.

Assessment

• No obvious FastAPI runtime performance regression.
• Any performance effect would likely come indirectly from Pydantic version behavior, not new FastAPI logic.

Low — Public API design patterns appear stable in the inspected window

I did not see new framework abstractions or public API design changes in the recent window. Impact is mostly packaging/schema compatibility, not endpoint ergonomics.

Suggested follow-ups

1. Explicitly call out the Pydantic minimum-version bump as a compatibility-impacting change.
2. Re-evaluate whether the lower bound truly must be 2.9.0 for runtime correctness.
3. Split tests into:
   • version-tolerant compatibility assertions
   • strict FastAPI invariants
4. If newer Pydantic versions are required for correctness or performance, document that rationale directly in the PR/release notes.

Bottom line

This change set looks mechanically safe, but semantically it has a meaningful compatibility smell: a patch release tightening a core dependency floor is something users may reasonably experience as a breaking change.