Question
FastAPI Dependency Injection: Managing Sub-dependency Cache in Complex Request Lifecycles
Rey Lane
0 reputation · 26 Jun 2022, 07:18 UTC
94K views
Loading…
0 reputation · 26 Jun 2022, 07:18 UTC
FastAPI utilizes the Depends class to manage resources, where sub-dependencies are cached by default within a single request scope to prevent redundant executions. This behavior ensures that if multiple dependencies require the same database session or security scheme, the logic executes only once per request.
While app.dependency_overrides allows for replacing production logic with mocks during testing, the interaction between cached sub-dependencies and nested dependency trees can create ambiguity when specific request-level state changes are required mid-lifecycle.
There is a need to clarify the behavior when the use_cache parameter is set to False in a deeply nested hierarchy. It is unclear if disabling the cache at a top-level dependency propagates to all its child dependencies or if each node in the tree must be explicitly configured.
use_cache=False on a parent dependency force the re-execution of all nested sub-dependencies?use_cache settings when the same dependency is required by two different branches of the tree with conflicting cache configurations?No. Setting use_cache=False on a parent dependency does not force re-execution of its nested sub-dependencies. The flag is local to the Depends node where it is declared. Each dependency in the tree controls only its own callable.
FastAPI caches dependency results per request, keyed by the dependency callable itself. When you write Depends(get_db, use_cache=False), you are telling the resolver not to reuse a cached get_db result at that position. Sub-dependencies declared inside get_db's signature are separate Depends nodes. They keep their own default (use_cache=True) unless you explicitly set the flag on each one.
There is no global priority rule. If the same callable is required by two branches with conflicting settings:
python
fastapiuse_cache=True node uses the cached value if one already exists.use_cache=False node always calls the function again.Because FastAPI resolves dependencies in declaration order, the branch that executes first can populate or replace the cache. A later default branch may therefore receive the re-executed value if the uncached branch ran first. The observable behavior is order-dependent, not determined by a fixed hierarchy.
Be especially careful with yield dependencies. An uncached yield dependency enters the request exit stack on every execution, so setup and teardown code can run multiple times in a single request if multiple uncached nodes reference it.
While the non-inheritance of use_cache=False is consistent, the exact cache-update semantics for uncached nodes have varied across FastAPI releases. Before relying on order-dependent outcomes, verify against your installed version.
Create a shared sub-dependency that increments a counter. Require it from two parent dependencies, one with use_cache=False and one with the default. Log the call count per request, then swap the order of the parents in the route signature to observe which value the default branch receives.
If you share your FastAPI version, I can confirm whether the cache-replacement behavior in your release matches the order-dependent model described above.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.