Update dependency fastapi to v0.135.1#22
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughFastAPI dependency version updated from 0.131.0 to 0.135.0 in Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 1 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
setup.cfg (1)
15-15:python_requiresis stale relative to FastAPI's minimum supported Python version.
python_requires = >=3.6allows installation on Python 3.6–3.8, but FastAPI dropped Python 3.8 support starting in 0.125.0 — the classifiers in this same file already declare only Python 3.9, which is consistent with the FastAPI minimum, but thepython_requiresconstraint hasn't been updated. This misleads package installers and tooling into believing Python 3.6/3.7/3.8 are valid runtimes.🛠️ Proposed fix
-python_requires = >=3.6 +python_requires = >=3.9🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@setup.cfg` at line 15, The python_requires setting is stale: update the python_requires entry (the "python_requires" key in setup.cfg) from ">=3.6" to ">=3.9" so it matches the package classifiers and FastAPI's minimum supported Python version; ensure the classifiers block still lists Python 3.9+ to keep metadata consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@requirements.txt`:
- Line 1: FastAPI 0.132.0 enables strict_content_type=True by default which will
reject JSON requests missing a proper Content-Type header; confirm all upstream
callers that send JSON bodies set Content-Type: application/json, and if any
cannot be changed, update the app instantiation by passing
strict_content_type=False to the FastAPI() constructor (or adjust any middleware
that constructs requests) so non-compliant clients continue to work; note tests
using FastAPI.testclient.TestClient with json= already set the header and need
no changes.
- Line 1: requirements.txt currently pins fastapi but a transitive dependency
pulls in vulnerable urllib3 1.26.20; identify which direct package (likely boto3
or sentry-sdk) depends on urllib3 1.26.20 (use pipdeptree or pip index
dependents) and update that direct dependency to a version that requires urllib3
>= 2.6.3, or add an explicit top-level constraint like urllib3>=2.6.3 to
requirements.txt to force the patched release; reference the manifest file
requirements.txt and candidate direct deps like boto3 and sentry-sdk when
locating and changing the version.
---
Nitpick comments:
In `@setup.cfg`:
- Line 15: The python_requires setting is stale: update the python_requires
entry (the "python_requires" key in setup.cfg) from ">=3.6" to ">=3.9" so it
matches the package classifiers and FastAPI's minimum supported Python version;
ensure the classifiers block still lists Python 3.9+ to keep metadata
consistent.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting
📒 Files selected for processing (2)
requirements.txtsetup.cfg
requirements.txt
Outdated
| @@ -1,4 +1,4 @@ | |||
| fastapi==0.131.0 | |||
| fastapi==0.132.0 | |||
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
FastAPI 0.132.0 strict_content_type breaking change release notes
💡 Result:
FastAPI 0.132.0 (released Feb 23, 2026) includes a breaking change: it enables strict Content-Type checking for JSON request bodies by default (strict_content_type=True). Requests with JSON bodies that don’t send a valid JSON media type (e.g. application/json, application/*+json) in the Content-Type header are rejected / not parsed as JSON. If you must support clients that omit or send an invalid Content-Type, you can disable the behavior with FastAPI(strict_content_type=False) (or equivalent configuration in your app setup). [1] [2] [3]
Release notes entry: “Add strict_content_type checking for JSON requests.” (PR #14978). [1] [3]
Docs: “Strict Content-Type Checking” explains the default behavior, rationale (CSRF risk scenario), and the strict_content_type=False opt-out. [2]
Sources: [1] FastAPI Release Notes (0.132.0) • [2] FastAPI docs: Strict Content-Type Checking • [3] GitHub release 0.132.0 / PR #14978
🏁 Script executed:
# First, explore the repository structure to understand test layout
git ls-files | grep -E "(test|spec)" | head -20Repository: RedHatInsights/ccx-upgrades-inference
Length of output: 343
🏁 Script executed:
# Search for httpx usage in test files
rg -n "httpx" --type py -B 2 -A 3 | head -100Repository: RedHatInsights/ccx-upgrades-inference
Length of output: 63
🏁 Script executed:
# Look specifically for httpx client.post/put/patch calls with content= or data= parameters
rg -n "\.post\(|\.put\(|\.patch\(" --type py --glob "*test*" -B 1 -A 2 | head -150Repository: RedHatInsights/ccx-upgrades-inference
Length of output: 63
🏁 Script executed:
# List all test files and their sizes
find . -name "test_*.py" -type f -exec wc -l {} \; | sort -nRepository: RedHatInsights/ccx-upgrades-inference
Length of output: 279
🏁 Script executed:
# Check test_main.py for httpx usage and patterns
cat -n ccx_upgrades_inference/tests/test_main.py | head -100Repository: RedHatInsights/ccx-upgrades-inference
Length of output: 1675
🏁 Script executed:
# Check if httpx is actually imported/used anywhere in test files
rg -n "import httpx|from httpx" ccx_upgrades_inference/tests/Repository: RedHatInsights/ccx-upgrades-inference
Length of output: 63
🏁 Script executed:
# Double-check all test files for content= or data= patterns
rg -n "content=|data=" ccx_upgrades_inference/tests/ --type pyRepository: RedHatInsights/ccx-upgrades-inference
Length of output: 63
🏁 Script executed:
# Check requirements.txt to see actual dependencies
cat -n requirements.txtRepository: RedHatInsights/ccx-upgrades-inference
Length of output: 502
Verify upstream clients send Content-Type: application/json for FastAPI 0.132.0.
FastAPI 0.132.0 now enforces strict_content_type=True by default, rejecting JSON requests that lack a valid JSON Content-Type header (e.g., application/json). Before merging, confirm all upstream callers sending JSON bodies explicitly set this header. If clients cannot be updated, pass strict_content_type=False to the FastAPI() constructor.
Note: The existing test suite uses FastAPI.testclient.TestClient with the json= parameter, which automatically sets the correct header, so no test changes are required.
🧰 Tools
🪛 OSV Scanner (2.3.3)
[HIGH] 1-1: urllib3 1.26.20: urllib3 streaming API improperly handles highly compressed data
[HIGH] 1-1: urllib3 1.26.20: Decompression-bomb safeguards bypassed when following HTTP redirects (streaming API)
[HIGH] 1-1: urllib3 1.26.20: urllib3 allows an unbounded number of links in the decompression chain
[HIGH] 1-1: urllib3 1.26.20: urllib3 redirects are not disabled when retries are disabled on PoolManager instantiation
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@requirements.txt` at line 1, FastAPI 0.132.0 enables strict_content_type=True
by default which will reject JSON requests missing a proper Content-Type header;
confirm all upstream callers that send JSON bodies set Content-Type:
application/json, and if any cannot be changed, update the app instantiation by
passing strict_content_type=False to the FastAPI() constructor (or adjust any
middleware that constructs requests) so non-compliant clients continue to work;
note tests using FastAPI.testclient.TestClient with json= already set the header
and need no changes.
🧩 Analysis chain
🏁 Script executed:
# Search for all dependency-related files
find . -type f \( -name "requirements*.txt" -o -name "setup.py" -o -name "setup.cfg" -o -name "pyproject.toml" -o -name "Pipfile" -o -name "Pipfile.lock" -o -name "poetry.lock" -o -name "*.lock" \) 2>/dev/null | head -20Repository: RedHatInsights/ccx-upgrades-inference
Length of output: 128
🏁 Script executed:
# List all files in the root directory to get a sense of project structure
ls -la | head -30Repository: RedHatInsights/ccx-upgrades-inference
Length of output: 1236
🏁 Script executed:
# Check the full content of requirements.txt to see all direct dependencies
cat requirements.txt 2>/dev/nullRepository: RedHatInsights/ccx-upgrades-inference
Length of output: 397
🏁 Script executed:
cat pyproject.tomlRepository: RedHatInsights/ccx-upgrades-inference
Length of output: 383
🏁 Script executed:
# Let's check what version of boto3, httpx, and sentry-sdk actually depend on urllib3
# First, let's see if we can get more info from setup.cfg
cat setup.cfgRepository: RedHatInsights/ccx-upgrades-inference
Length of output: 647
🏁 Script executed:
# Search for any lock files or dependency specifications that might show resolved versions
git ls-files | grep -E "(lock|freeze)" | head -20Repository: RedHatInsights/ccx-upgrades-inference
Length of output: 63
🏁 Script executed:
# Try to determine the urllib3 dependency chain by examining what versions of key packages would pull it
# We'll use Python to simulate pip dependency resolution
python3 << 'EOF'
import subprocess
import sys
# Try to get dependency info for the key suspects
packages = [
"boto3",
"httpx==0.28.1",
"sentry-sdk>=1.37.1",
"watchtower",
"python-json-logger"
]
for pkg in packages:
try:
# Use pip show to get metadata about the package
result = subprocess.run([sys.executable, "-m", "pip", "show", pkg.split("==")[0].split(">=")[0]],
capture_output=True, text=True, timeout=5)
if result.returncode == 0:
lines = result.stdout.split('\n')
for line in lines:
if 'Requires' in line:
print(f"{pkg}: {line}")
except:
pass
EOFRepository: RedHatInsights/ccx-upgrades-inference
Length of output: 136
🏁 Script executed:
# Check boto3 and sentry-sdk transitive dependencies
python3 << 'EOF'
import subprocess
import sys
packages = {
"boto3": None,
"sentry-sdk": ">=1.37.1",
"watchtower": None,
}
for pkg, version in packages.items():
pkg_spec = f"{pkg}{version}" if version else pkg
try:
# First install/check the package
result = subprocess.run(
[sys.executable, "-m", "pip", "show", pkg, "-v"],
capture_output=True, text=True, timeout=10
)
if result.returncode == 0:
print(f"\n=== {pkg_spec} ===")
for line in result.stdout.split('\n'):
if any(x in line for x in ['Requires', 'Version', 'Name']):
print(line)
except Exception as e:
print(f"Error checking {pkg}: {e}")
EOFRepository: RedHatInsights/ccx-upgrades-inference
Length of output: 63
🌐 Web query:
urllib3 1.26.20 GHSA-2xpw-w6gg-jr37 streaming API compressed data vulnerability
💡 Result:
GHSA-2xpw-w6gg-jr37 (aka CVE-2025-66471, published Dec 5, 2025) is a resource-exhaustion (client DoS) issue in urllib3’s streaming API when handling compressed HTTP responses. A small, highly-compressed response can be decompressed in a single operation into a very large amount of data, causing high CPU and massive memory allocation, even if your code only reads small chunks. Affected streaming calls include stream(), read(amt=...), read1(), read_chunked(), and readinto(). [1][2]
Is urllib3==1.26.20 affected?
Yes. The affected range is all versions >= 1.0 and < 2.6.0, so 1.26.20 is vulnerable. [1][2]
Fix
- Upgrade to
urllib3 >= 2.6.0(the first patched release). [1][2]
Some scanners/tools recommend upgrading further (e.g.,>= 2.6.3). [3]
Workarounds (if you can’t upgrade immediately)
- Disable content decoding / decompression when streaming (i.e., avoid automatically decoding compressed responses from untrusted sources). [1]
Sources: GitHub Advisory Database [1], GitLab Advisory Database [2], Snyk advisory entry [3].
[1] GHSA-2xpw-w6gg-jr37
[2] https://advisories.gitlab.com/pkg/pypi/urllib3/CVE-2025-66471/
[3] https://security.snyk.io/package/pip/urllib3/1.26.20
🌐 Web query:
urllib3 GHSA-38jv-5279-wg99 decompression bomb redirect
💡 Result:
GHSA-38jv-5279-wg99 (CVE-2026-21441) – urllib3 “decompression bomb via redirect”
- What it is: In urllib3’s streaming mode (
preload_content=False), if HTTP redirects are followed, urllib3 would drain the redirect response body by fully decoding/decompressing it (based onContent-Encoding) even before you read from the response. This bypassed normal streaming/read limits, so a malicious server could send a decompression bomb and cause client-side DoS (excessive CPU and memory use). [1][2] - When you’re affected: Using urllib3 to stream content from untrusted sources with
preload_content=Falseand redirects enabled. [1][2] - Affected versions: >= 1.22 and < 2.6.3 (often summarized as “2.6.2 and earlier” for the 2.x line). [1][2]
- Fix: Upgrade to urllib3 2.6.3+ (redirect responses are no longer decoded when
preload_content=False). [1][2] - Workaround (if you can’t upgrade): Disable redirects for untrusted URLs (set
redirect=False). [1][2]
Sources: GitHub security advisory (urllib3) [1], NVD CVE record [2].
🌐 Web query:
urllib3 GHSA-gm62-xv2j-4w53 unbounded decompression chain
💡 Result:
GHSA-gm62-xv2j-4w53 (CVE-2025-66418) — urllib3 “unbounded decompression chain”
- What it is:
urllib3supports chained response decoders viaContent-Encoding(e.g.,gzip, zstd). A malicious server can send an unbounded number of encodings, causing excessive CPU work and memory allocation during decompression (Denial of Service). [1][2] - Affected versions:
urllib3>= 1.24 and < 2.6.0. [1][3] - Fixed version: 2.6.0 (limits the decompression-chain length to 5). [1][2]
- Who is practically at risk: Clients making HTTP requests to untrusted servers while automatic content decoding is enabled (notably called out for urllib3 2.5.0 and earlier). [1][2]
- Mitigations if you can’t upgrade immediately: Avoid auto-decoding by using
preload_content=False, and validate thatContent-Encodingcontains only a safe/small number of encodings before reading the body. [1]
Sources:
[1] GitHub Security Advisory (urllib3): GHSA-gm62-xv2j-4w53 — Unbounded number of links in the decompression chain
[2] OSV entry: GHSA-gm62-xv2j-4w53
[3] GitLab Advisory Database: CVE-2025-66418
🌐 Web query:
urllib3 GHSA-pq67-6m6q-mj2v redirects disabled retries PoolManager
💡 Result:
GHSA-pq67-6m6q-mj2v (CVE-2025-50181) is an urllib3 redirect-control bug: in urllib3 versions < 2.5.0, if you try to disable or limit redirects globally by passing retries when creating a PoolManager (e.g., PoolManager(retries=0), PoolManager(retries=False), or PoolManager(retries=Retry(redirect=0))), urllib3 ignores that setting and will still follow redirects. This can undermine SSRF/open-redirect mitigations that rely on “no redirects” at the pool/manager level. [1]
Who’s affected: code that depends on PoolManager(retries=...) to control redirects; “by default, requests and botocore users are not affected.” [1]
Fix / remediation:
- Upgrade to urllib3 2.5.0+ (the issue is patched there). [2]
- If you can’t upgrade immediately, disable redirects per request (e.g.,
http.request(..., redirect=False)/urllib3.request(..., redirect=False)) rather than relying onPoolManager(retries=...). [1]
Severity: Moderate (CVSS 5.3). [1]
Sources: [1] GitHub advisory GHSA-pq67-6m6q-mj2v, [2] GitLab advisory for CVE-2025-50181.
Update transitive urllib3 dependency to patch known vulnerabilities.
The OSV scanner flags urllib3 1.26.20 (a transitive dependency) with four advisories, three of which are HIGH severity:
| Advisory | Severity | Summary |
|---|---|---|
| GHSA-2xpw-w6gg-jr37 | HIGH | Streaming API improperly handles highly compressed data |
| GHSA-38jv-5279-wg99 | HIGH | Decompression-bomb safeguards bypassed on HTTP redirects |
| GHSA-gm62-xv2j-4w53 | HIGH | Unbounded decompression chain |
| GHSA-pq67-6m6q-mj2v | MODERATE | Redirects not disabled when retries are disabled on PoolManager |
These are pre-existing in the dependency tree (not introduced by this PR). Identify which direct dependency (likely boto3 or sentry-sdk) pulls in urllib3 1.26.20 and update it to bring in a patched version (urllib3 >= 2.6.3 preferred).
🧰 Tools
🪛 OSV Scanner (2.3.3)
[HIGH] 1-1: urllib3 1.26.20: urllib3 streaming API improperly handles highly compressed data
[HIGH] 1-1: urllib3 1.26.20: Decompression-bomb safeguards bypassed when following HTTP redirects (streaming API)
[HIGH] 1-1: urllib3 1.26.20: urllib3 allows an unbounded number of links in the decompression chain
[HIGH] 1-1: urllib3 1.26.20: urllib3 redirects are not disabled when retries are disabled on PoolManager instantiation
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@requirements.txt` at line 1, requirements.txt currently pins fastapi but a
transitive dependency pulls in vulnerable urllib3 1.26.20; identify which direct
package (likely boto3 or sentry-sdk) depends on urllib3 1.26.20 (use pipdeptree
or pip index dependents) and update that direct dependency to a version that
requires urllib3 >= 2.6.3, or add an explicit top-level constraint like
urllib3>=2.6.3 to requirements.txt to force the patched release; reference the
manifest file requirements.txt and candidate direct deps like boto3 and
sentry-sdk when locating and changing the version.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #22 +/- ##
=======================================
Coverage 86.93% 86.93%
=======================================
Files 10 10
Lines 199 199
Branches 6 6
=======================================
Hits 173 173
Misses 25 25
Partials 1 1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
3d26d2f to
e832869
Compare
There was a problem hiding this comment.
♻️ Duplicate comments (1)
requirements.txt (1)
1-1: FastAPI 0.132.0 strict Content-Type behavior—already flagged earlier.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@requirements.txt` at line 1, The requirements pin currently targets fastapi==0.133.0 which reintroduces strict Content-Type handling; update the dependency line in requirements.txt to fastapi==0.132.0 (or the approved compatible version) so the app retains the previous non-strict Content-Type behavior, and ensure any CI or dependency files referencing FastAPI are updated consistently.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@requirements.txt`:
- Line 1: The requirements pin currently targets fastapi==0.133.0 which
reintroduces strict Content-Type handling; update the dependency line in
requirements.txt to fastapi==0.132.0 (or the approved compatible version) so the
app retains the previous non-strict Content-Type behavior, and ensure any CI or
dependency files referencing FastAPI are updated consistently.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting
📒 Files selected for processing (2)
requirements.txtsetup.cfg
e832869 to
5233263
Compare
|
/retest |
|
/retest |
5233263 to
c0ea1b0
Compare
c0ea1b0 to
ea57fd6
Compare
Signed-off-by: red-hat-konflux <126015336+red-hat-konflux[bot]@users.noreply.github.com>
ea57fd6 to
1436339
Compare
|
/retest |
|
/retest |
Edited/Blocked NotificationRenovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR. You can manually request rebase by checking the rebase/retry box above. |
|
/retest |
6 similar comments
|
/retest |
|
/retest |
|
/retest |
|
/retest |
|
/retest |
|
/retest |
This PR contains the following updates:
==0.131.0->==0.135.1Release Notes
fastapi/fastapi (fastapi)
v0.135.1Compare Source
Fixes
Docs
docs/en/docs/_llm-test.md. PR #15007 by @adityagiri3600.Internal
v0.135.0Compare Source
Features
v0.134.0Compare Source
Features
yield. PR #15022 by @tiangolo.>=0.40.0to>=0.46.0, as it's needed to properly unrwap and re-raise exceptions from exception groups.Docs
yield. PR #15023 by @tiangolo.awaitinStreamingResponsecode example to allow cancellation. PR #14681 by @casperdcl.docs_src/websocketstodocs_src/websockets_to avoid import errors. PR #14979 by @YuriiMotov.Internal
pytest-xdistandpytest-cov. PR #14992 by @YuriiMotov.v0.133.1Compare Source
Features
Internal
v0.133.0Compare Source
Upgrades
v0.132.1Compare Source
Refactors
Internal
benchmarkjob intestworkflow. PR #14974 by @YuriiMotov.v0.132.0Compare Source
Breaking Changes
strict_content_typechecking for JSON requests. PR #14978 by @tiangolo.Content-Typeheader with a valid JSON value, likeapplication/json, and rejects requests that don't.Content-Typeheader you can disable this withstrict_content_type=False.Internal
griffelibinstead ofgriffe. PR #14973 by @svlandeg.FastAPI Peopleworkflow. PR #14951 by @YuriiMotov.Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
To execute skipped test pipelines write comment
/ok-to-test.Documentation
Find out how to configure dependency updates in MintMaker documentation or see all available configuration options in Renovate documentation.