Will instances of injected dependencies be reused when depended upon multiple times?

[mrdeveloperdude]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google "How to X in FastAPI" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

• I commit to help with one of those options 👆

Example Code

from fastapi import FastAPI, Depends

app = FastAPI()

# Assuming this is your Context class
class Context:
    def __init__(self, auth_info: str):
        self.auth_info = auth_info
        # Initialize your database connection here

# Your BatchProcessor class that depends on Context
class BatchProcessor:
    def __init__(self, context: Context):
        self.context = context
        # Use context to access db connection, auth info, etc.

# Dependency that produces a Context object
def get_context() -> Context:
    # Create and return a Context instance
    # For example, auth_info could come from request headers
    return Context(auth_info="User XYZ")

# Dependency that produces a BatchProcessor object, depends on Context
def get_batch_processor(context: Context = Depends(get_context)) -> BatchProcessor:
    return BatchProcessor(context=context)

# An endpoint that depends on both Context and BatchProcessor
@app.get("/my_endpoint")
async def my_endpoint(context: Context = Depends(get_context), 
                      batch_processor: BatchProcessor = Depends(get_batch_processor)):
    # Here, you can use both context and batch_processor as needed
    return {"message": "Using both Context and BatchProcessor"}

Description

I am using Depends for the first time and so far it was good to me. However I stumble a little in edge cases. Let me present the sample code;

I have 2 dependencies

• Context which is for MOST endpoints and contains such thins as application config, database connection etc.

• BatchProcessor which is for SOME endpoints and contains some resources specific to part of the application.

Every endpoint that depends on BatchProcessor ALSO depend on Context.

Every endpoint basically need access to the context directly, even if it also needs access to batch_processor.

And here is the question: Will the context that my endpoint gains access to in the example code be the same instance as the one provided to BatchProcessor, or will I have two distict instances of this class? How can I understand why/how (how does FastAPI do this under the hood)?

I looked at the official documentation trying to learn about this, but it is on a much shallower level.

Operating System

Linux

Operating System Details

Not relevant

FastAPI Version

0.103.2

Pydantic Version

2.4.0

Python Version

3.9.2

Additional Context

No response

[YuriiMotov]

Yes, in your case the result of get_context will be cached and it will be the same object during one endpoint call.
Doc: https://fastapi.tiangolo.com/tutorial/dependencies/sub-dependencies/#using-the-same-dependency-multiple-times

To test that you can add assert context == batch_processor.context to your endpoint code:

# An endpoint that depends on both Context and BatchProcessor
@app.get("/my_endpoint")
async def my_endpoint(context: Context = Depends(get_context), 
                      batch_processor: BatchProcessor = Depends(get_batch_processor)):
    # Here, you can use both context and batch_processor as needed

    assert context == batch_processor.context

    return {"message": "Using both Context and BatchProcessor"}

You can also add debug print to the __init__ method of Context to make sure that it's called only once:

class Context:
    def __init__(self, auth_info: str):
        self.auth_info = auth_info
        print("Create Context")
        # Initialize your database connection here

[mrdeveloperdude]

I feel kind of silly now, it was right there. 🤦 I will mark this as the solution. However I will use this opportunity to add some extra questions to make this even more clear.

How are the signatures of dependencies compared to determine they are the same? Is it the type only, or does the "delivery" function also matter?

For example, can I have one context:Context = delivery_method_1 and another context:Context = delivery_method_2 and they will still be considered the same?

Also, how about inheritance? For example what if I have context:Context = whatever and context:ExtendedContext = whatever where ExtendedContext inherits from Context.

I realize these are fringe cases, but it would greatly aid my understanding to know what would happen in these cases.

[YuriiMotov]

The 'Key' to store cached solved dependency is calculated using 'dependency callable' and 'security scopes' (you can use Security instead of Depends and pass scopes parameter. For now I think you can just skip it).
So, in the example below, context_1 and context_2 will be equal (callable is the same (get_context) and scopes are the same (empty)):

@app.get("/my_endpoint")
async def my_endpoint(
    context_1: Context = Depends(get_context), 
    context_2: Context = Depends(get_context), 
):
    assert context_1 == context_2

Answering your questions (you missed Depends(), I added it):

How are the signatures of dependencies compared to determine they are the same? Is it the type only, or does the "delivery" function also matter?
For example, can I have one context:Context = Depends(delivery_method_1) and another context:Context = Depends(delivery_method_2) and they will still be considered the same?

They are not the same since functions inside Depends() are different.

Also, how about inheritance? For example what if I have context:Context = Depends(whatever) and context:ExtendedContext = Depends(whatever) where ExtendedContext inherits from Context.

It doesn't matter what are the name of variables and what are their types, the only thing that matter here is what is inside Depends()

[YuriiMotov]

If you want to dive deeper, this post describing some of the issues (potential) in dependency caching will probably be interesting to you: #6024 (comment)