Cache detector overcomes boundaries of instances

[dhofstetter]

Hey together :)
awesome project 👍 I really like the way its built!

I have found a bug/question not sure yet ;)

I've setup a FastAPI application and setup two caches

• the default one (cashews.cache)
• a separate instance for internal usage only (e.g. cache some db calls or whatsoever)

I separated the two, because I wanted to ensure, that whenever I use my "separate internal" cache, the calls won't get detected by the middleware. Why? Because if they get caught, the etag is literally based on the latest call to the internal cache, which might not be anyhow related to the content returned, you understand?

I thought by using a separate cache instance, I can ensure that the call detector (internally used by etag middleware), cannot see this cache invocations and thus no etag gets created in this case.

The thing is that by having this behavior I constantly get things etagged I don't want to have etagged. In combination with htmx usage, this can mess things up pretty badly ;)

Questions

• is it expected that the cache call detector overcomes cache instance boundaries
• if so, how can I generate etags only on fastapi routes that uses a specific cache instance?
• is it generally the case that etags get computed based on data payload only (excluding headers and url)?

[Krukov]

Hello,

Initially, this was implemented in a simple way: the call detector crosses cache instance boundaries; it's just a single ContextVar.

But I planned for each cache instance to have its own detector, so I made it a cache attribute but didn't implement "context boundaries»

So we can consider this is a bug.