Closed robert-schmidtke closed 4 months ago
I actually noted that a straightforward fix for this would be to use dedicated Cache
instances, rather than reusing the default cache
.
Hello,
Nice case but unfortunately any application that use a shared state , like tasks lists or connections pool, will have problems with multiple loops ( like problem with redis that you mentioned in PR ) So probably if you can fix it with separated/dedicated Cache instance that would be a better solution.
Closing as the workaround is more versatile anyway and available today already.
Hi, I am using
cashews
within the "main" event loop, as well as within worker threads with their own event loops.The "main" event loop is from a FastAPI application (Uvicorn, uvloop), whereas the other loops I have to create manually and run them in dedicated threads. This is so I can use the async-only
cashews
library to cache method calls within a synchronous 3rd party library which I have hooked into.The snippet below distills the setup and also shows an error I am facing when doing so. I believe the reason is that the
thunder_protection
caches tasks regardless of what loop they're running in, which means the currently running loop when doingawait tasks[_key]
might be different from the one that put it there. When usingprotected=False
, the issue does not appear.I have fixed this locally using context local tasks caching instead of global task caching, and will open a PR shortly that illustrates this.