Skip to content

chore(deps): bump fastapi in /apps/crm-campaign-intelligence/src#1148

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/uv/apps/crm-campaign-intelligence/src/uv-ded46000bd
Open

chore(deps): bump fastapi in /apps/crm-campaign-intelligence/src#1148
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/uv/apps/crm-campaign-intelligence/src/uv-ded46000bd

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Jun 15, 2026

Copy link
Copy Markdown
Contributor

Bumps fastapi in /apps/crm-campaign-intelligence/src from 0.136.3 to 0.137.0.

Updates fastapi from 0.136.3 to 0.137.0

Release notes

Sourced from fastapi's releases.

0.137.0

Breaking Changes

  • ♻️ Refactor internals to preserve APIRouter and APIRoute instances. PR #15745 by @​tiangolo.

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

  • Adding routes (path operations) after a router is included now works, they are reflected as they are not copied.
  • Including subrouter in mainrouter can be done before adding routes (path operations) to subrouter, because now the the entire object is stored instead of copying the routes.
  • As routes are not copied, in some cases that might save some memory.

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

  • Custom APIRoute subclasses (undocumented, but alraedy works as desccribed above)
  • Custom APIRouter subclasses (undocumented, but already works as described above)
  • Dependencies per router
  • Exception handlers per router
  • Middleware per router

... (truncated)

Commits

Updates fastapi from 0.136.3 to 0.137.0

Release notes

Sourced from fastapi's releases.

0.137.0

Breaking Changes

  • ♻️ Refactor internals to preserve APIRouter and APIRoute instances. PR #15745 by @​tiangolo.

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

  • Adding routes (path operations) after a router is included now works, they are reflected as they are not copied.
  • Including subrouter in mainrouter can be done before adding routes (path operations) to subrouter, because now the the entire object is stored instead of copying the routes.
  • As routes are not copied, in some cases that might save some memory.

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

  • Custom APIRoute subclasses (undocumented, but alraedy works as desccribed above)
  • Custom APIRouter subclasses (undocumented, but already works as described above)
  • Dependencies per router
  • Exception handlers per router
  • Middleware per router

... (truncated)

Commits

Updates fastapi from 0.136.3 to 0.137.0

Release notes

Sourced from fastapi's releases.

0.137.0

Breaking Changes

  • ♻️ Refactor internals to preserve APIRouter and APIRoute instances. PR #15745 by @​tiangolo.

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

  • Adding routes (path operations) after a router is included now works, they are reflected as they are not copied.
  • Including subrouter in mainrouter can be done before adding routes (path operations) to subrouter, because now the the entire object is stored instead of copying the routes.
  • As routes are not copied, in some cases that might save some memory.

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

  • Custom APIRoute subclasses (undocumented, but alraedy works as desccribed above)
  • Custom APIRouter subclasses (undocumented, but already works as described above)
  • Dependencies per router
  • Exception handlers per router
  • Middleware per router

... (truncated)

Commits

Updates fastapi from 0.136.3 to 0.137.0

Release notes

Sourced from fastapi's releases.

0.137.0

Breaking Changes

  • ♻️ Refactor internals to preserve APIRouter and APIRoute instances. PR #15745 by @​tiangolo.

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

  • Adding routes (path operations) after a router is included now works, they are reflected as they are not copied.
  • Including subrouter in mainrouter can be done before adding routes (path operations) to subrouter, because now the the entire object is stored instead of copying the routes.
  • As routes are not copied, in some cases that might save some memory.

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

  • Custom APIRoute subclasses (undocumented, but alraedy works as desccribed above)
  • Custom APIRouter subclasses (undocumented, but already works as described above)
  • Dependencies per router
  • Exception handlers per router
  • Middleware per router

... (truncated)

Commits

Updates fastapi from 0.136.3 to 0.137.0

Release notes

Sourced from fastapi's releases.

0.137.0

Breaking Changes

  • ♻️ Refactor internals to preserve APIRouter and APIRoute instances. PR #15745 by @​tiangolo.

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

  • Adding routes (path operations) after a router is included now works, they are reflected as they are not copied.
  • Including subrouter in mainrouter can be done before adding routes (path operations) to subrouter, because now the the entire object is stored instead of copying the routes.
  • As routes are not copied, in some cases that might save some memory.

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

  • Custom APIRoute subclasses (undocumented, but alraedy works as desccribed above)
  • Custom APIRouter subclasses (undocumented, but already works as described above)
  • Dependencies per router
  • Exception handlers per router
  • Middleware per router

... (truncated)

Commits

Updates fastapi from 0.136.3 to 0.137.0

Release notes

Sourced from fastapi's releases.

0.137.0

Breaking Changes

  • ♻️ Refactor internals to preserve APIRouter and APIRoute instances. PR #15745 by @​tiangolo.

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

  • Adding routes (path operations) after a router is included now works, they are reflected as they are not copied.
  • Including subrouter in mainrouter can be done before adding routes (path operations) to subrouter, because now the the entire object is stored instead of copying the routes.
  • As routes are not copied, in some cases that might save some memory.

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

  • Custom APIRoute subclasses (undocumented, but alraedy works as desccribed above)
  • Custom APIRouter subclasses (undocumented, but already works as described above)
  • Dependencies per router
  • Exception handlers per router
  • Middleware per router

... (truncated)

Commits

Updates fastapi from 0.136.3 to 0.137.0

Release notes

Sourced from fastapi's releases.

0.137.0

Breaking Changes

  • ♻️ Refactor internals to preserve APIRouter and APIRoute instances. PR #15745 by @​tiangolo.

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

  • Adding routes (path operations) after a router is included now works, they are reflected as they are not copied.
  • Including subrouter in mainrouter can be done before adding routes (path operations) to subrouter, because now the the entire object is stored instead of copying the routes.
  • As routes are not copied, in some cases that might save some memory.

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

  • Custom APIRoute subclasses (undocumented, but alraedy works as desccribed above)
  • Custom APIRouter subclasses (undocumented, but already works as described above)
  • Dependencies per router
  • Exception handlers per router
  • Middleware per router

... (truncated)

Commits

Updates fastapi from 0.136.3 to 0.137.0

Release notes

Sourced from fastapi's releases.

0.137.0

Breaking Changes

  • ♻️ Refactor internals to preserve APIRouter and APIRoute instances. PR #15745 by @​tiangolo.

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

  • Adding routes (path operations) after a router is included now works, they are reflected as they are not copied.
  • Including subrouter in mainrouter can be done before adding routes (path operations) to subrouter, because now the the entire object is stored instead of copying the routes.
  • As routes are not copied, in some cases that might save some memory.

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

  • Custom APIRoute subclasses (undocumented, but alraedy works as desccribed above)
  • Custom APIRouter subclasses (undocumented, but already works as described above)
  • Dependencies per router
  • Exception handlers per router
  • Middleware per router

... (truncated)

Commits

Updates fastapi from 0.136.3 to 0.137.0

Release notes

Sourced from fastapi's releases.

0.137.0

Breaking Changes

  • ♻️ Refactor internals to preserve APIRouter and APIRoute instances. PR #15745 by @​tiangolo.

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

  • Adding routes (path operations) after a router is included now works, they are reflected as they are not copied.
  • Including subrouter in mainrouter can be done before adding routes (path operations) to subrouter, because now the the entire object is stored instead of copying the routes.
  • As routes are not copied, in some cases that might save some memory.

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

  • Custom APIRoute subclasses (undocumented, but alraedy works as desccribed above)
  • Custom APIRouter subclasses (undocumented, but already works as described above)
  • Dependencies per router
  • Exception handlers per router
  • Middleware per router

... (truncated)

Commits

Updates fastapi from 0.136.3 to 0.137.0

Release notes

Sourced from fastapi's releases.

0.137.0

Breaking Changes

  • ♻️ Refactor internals to preserve APIRouter and APIRoute instances. PR #15745 by @​tiangolo.

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

  • Adding routes (path operations) after a router is included now works, they are reflected as they are not copied.
  • Including subrouter in mainrouter can be done before adding routes (path operations) to subrouter, because now the the entire object is stored instead of copying the routes.
  • As routes are not copied, in some cases that might save some memory.

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

  • Custom APIRoute subclasses (undocumented, but alraedy works as desccribed above)
  • Custom APIRouter subclasses (undocumented, but already works as described above)
  • Dependencies per router
  • Exception handlers per router
  • Middleware per router

... (truncated)

Commits

Updates fastapi from 0.136.3 to 0.137.0

Release notes

Sourced from fastapi's releases.

0.137.0

Breaking Changes

  • ♻️ Refactor internals to preserve APIRouter and APIRoute instances. PR #15745 by @​tiangolo.

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

  • Adding routes (path operations) after a router is included now works, they are reflected as they are not copied.
  • Including subrouter in mainrouter can be done before adding routes (path operations) to subrouter, because now the the entire object is stored instead of copying the routes.
  • As routes are not copied, in some cases that might save some memory.

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

  • Custom APIRoute subclasses (undocumented, but alraedy works as desccribed above)
  • Custom APIRouter subclasses (undocumented, but already works as described above)
  • Dependencies per router
  • Exception handlers per router
  • Middleware per router

... (truncated)

Commits
  • 9a9c4ad 🔖 Release version 0.137.0 (#15748)
    • ...

    Description has been truncated

@dependabot
chore(deps): bump fastapi in /apps/crm-campaign-intelligence/src
a9bcf12 
Bumps [fastapi](https://github.com/fastapi/fastapi) in `/apps/crm-campaign-intelligence/src` from 0.136.3 to 0.137.0.


Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

Updates `fastapi` from 0.136.3 to 0.137.0
- [Release notes](https://github.com/fastapi/fastapi/releases)
- [Commits](fastapi/fastapi@0.136.3...0.137.0)

---
updated-dependencies:
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
- dependency-name: fastapi
  dependency-version: 0.137.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
  dependency-group: uv
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file python Python code quality labels Jun 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies Pull requests that update a dependency file python Python code quality

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants