The cache_key of Security is different with that of Depends. it has to be two sessions if you use di. You can return the session in get_current_user or create session in middleware.

I would like to resume the discussion on dependency caching.

I apologize in advance for the long text..

The documentation says that

If one of your dependencies is declared multiple times for the same path operation, for example, multiple dependencies have a common sub-dependency, FastAPI will know to call that sub-dependency only once per request.

But this is not true. In the current implementation, FastAPI caches dependencies according to the dependency name and scopes. Thus, one dependency that is used twice with different scopes will be called twice (and cached twice).

This is not entirely intuitive behavior and it is undesirable in some cases.
For example, this leads to the opening of two database sessions in the following example:

In the example above, get_db_session will be called twice because scopes are different ([] and ["me"]).

There are a few discussions on this topic:

1. This one
2. Discussion in the comments of PR 🐛 Fix cached dependencies when using a dependency in Security() and other places (e.g. Depends()) with different OAuth2 scopes #2945
3. Dependency is not being cached; dependency called multiple times #9513

And @DurandA has created a PR to fix this problem #9790.
That PR fixes that particular problem, and get_db_session will be called only once:

Even though this PR doesn't brake any other tests, I think it brakes the logic of scopes propagation.
Let's take a look at the following example:

Let's assume that get_current_user uses security_scopes.
In current implementation (FastAPI 0.109.2) FastAPI will call get_current_user twice with different scopes ([] and ["me"]).
And after merging of this PR (#9790) FastAPI will call it only once (with scopes = []).
I think that's incorrect.

Before summarizing, let`s take a look at one more example:

Let`s assume that:

• get_db_session doesn't use security_scopes in any way and it's subdependencies also doesn`t use it
• get_current_user uses security_scopes
• get_something doesn't use security_scopes itself, but it uses subdependency get_current_user that uses security_scopes
• get_something_2 doesn't use security_scopes itself, but it uses subdependency get_something that uses subdependency get_current_user that uses security_scopes

From my point of view it would be logical to call get_db_session once and cache it using key={function_name} (without scopes).
But both of get_current_user and get_something must be called twice and cached with the keys that include scopes.
Do you agree? ** Is this how it was supposed to work?**

I think it's important to take a deeper look and figure it out before making changes to avoid new mistakes.
I suggest discussing this issue and implementing this logic as it was intended. And we need to fix the documentation (describe dependency caching rules) along the way.