| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
Large 28-minor-version bump (0.111.0 → 0.139.0) with several documented breaking changes; worth a human confirming CI is green and the release notes were skimmed.
Extended reasoning...Single-line change to template/server/requirements.txt, bumping fastapi==0.111.0 to fastapi==0.139.0. This is the sandbox server template — the FastAPI app in template/server/main.py that runs inside every E2B code-interpreter sandbox and exposes /execute, /contexts, /health endpoints consumed by the JS and Python SDKs.
No direct security risk from the change itself. The version range does include a security-flavored change (v0.132.0 strict Content-Type checking) that hardens JSON parsing by default; both SDK clients already send Content-Type: application/json on POSTs, so this should be a net improvement rather than a regression.
Elevated. A Renovate one-line bump is normally trivially approvable, but jumping 28 minor versions crosses several documented breaking changes: v0.132.0 (strict_content_type), v0.134.0 (Starlette bumped to >=0.46.0), v0.136.3 (no more underscore headers with convert_underscores=True), v0.137.0 (router.routes is no longer a flat list). The template code is straightforward standard FastAPI, so I don't see a concrete break, but the runtime blast radius is high — this ships to every sandbox.
No bugs surfaced by the bug hunting system. No prior reviewer comments. No test exercise of this template file in the diff. Given the small textual change but high downstream impact, I'd rather a human confirm CI and eyeball the changelog than shadow-approve.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
This PR contains the following updates:
Release Notes
fastapi/fastapi (fastapi)v0.141.1
Compare Source
Fixes
Docs
v0.141.0
Compare Source
Features
v0.140.13
Compare Source
Fixes
Docs
v0.140.12
Compare Source
Fixes
v0.140.11
Compare Source
v0.140.10
Compare Source
Fixes
Internal
v0.140.9
Compare Source
Fixes
Internal
v0.140.8
Compare Source
Fixes
v0.140.7
Compare Source
Refactors
Internal
v0.140.6
Compare Source
Refactors
v0.140.5
Compare Source
Refactors
v0.140.4
Compare Source
v0.140.3
Compare Source
Refactors
v0.140.2
Compare Source
Refactors
Internal
v0.140.1
Compare Source
Refactors
v0.140.0
Compare Source
Refactors
Docs
Internal
v0.139.2
Compare Source
Fixes
v0.139.1
Compare Source
Fixes
Docs
Translations
Internal
v0.139.0
Compare Source
Features
Translations
Internal
v0.138.2
Compare Source
Refactors
Internal
v0.138.1
Compare Source
Refactors
Internal
v0.138.0
Compare Source
Features
Docs
Translations
Internal
v0.137.2
Compare Source
Features
Translations
Internal
v0.137.1
Compare Source
Fixes
v0.137.0
Compare Source
Breaking Changes
Unblocks ✨ SO MANY THINGS ✨
Before this, router.include_router(other_router) would take each path operation from other_router and "clone" it, or recreate it from scratch.
This would mean that in the end there was only one top level router, part of the app.
The way it is structured here is that there are a few additional classes to handle intermediate metadata for router and route inclusion. That way the information of "router X includes Y and Y includes Z" is stored somewhere, without affecting (recreating / clonning) the final route.
Non Objectives
Dependencies for 404: previously I intended to support dependencies that would be executed even for 404, but that would conflict with the fact that a router could not find a match, but the next router did find a match. Executing dependencies in the router that did not find a match would not make sense, they could consume the request, body, etc. This original idea was discarded.
Specific Breaking Changes
Now router.routes is no longer a plain list of APIRoute objects, it can contain these intermediate objects that can contain additional routers, forming a tree.
Any logic that depended on iterating on the router.routes directly would be affected, that logic cannot expect to be able to extract data from a plain list of routes, as it's no longer a plain list but a tree.
Additionally, any logic that iterated on router.routes to modify them would now also see these new objects, and would not see all the routes in the app.
router.routes should be considered an internal implementation detail, only passed around to the FastAPI functions that need it.
Features
Alpha Features
This is not documented yet, so it's not officially supported yet and could change in the future.
But, as APIRoute and APIRouter instances are now preserved, they could be customized.
APIRouter has two new methods, .matches() and .handle(), counterpart to the existing ones in APIRoute. With this a router could customize how it matches and handles requests. For example, it could match only requests that include some specific header, for example for handling versions in headers.
Still, for now, consider this very experimental and potentially changing and breaking in the future.
Future Features Enabled
Docs
Translations
Internal
v0.136.3
Compare Source
Refactors
v0.136.1
Compare Source
Upgrades
Internal
v0.136.0
Compare Source
Upgrades
v0.135.4
Compare Source
Refactors
Internal
v0.135.3
Compare Source
Features
Docs
Internal
v0.135.2
Compare Source
Upgrades
Docs
Configuration
📅 Schedule: (in timezone UTC)
🚦 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 this update again.
This PR was generated by Mend Renovate. View the repository job log.