Draft: Client side caching

[a-khakimov]

This is a draft implementation of Client Side Caching - #998.
This is roughly how I envision the interface — I’ll finish it soon and add usage examples.
Feel free to take a look; any questions or suggestions are very welcome!

[yisraelU]

we should be using the connection interface https://github.com/profunktor/redis4cats/blob/dd861e5f2cef45b2b0cfcf1aab0a5af5968f48a1/modules/core/src/main/scala/dev/profunktor/redis4cats/connection/RedisConnection.scala#L38C27-L38C42

[yisraelU]

the convention in this lib , is to create a scala api for the java pojo's . i.e.

[yisraelU]

putting aside the changes to TxExecutor, we should create a facade for CacheFrontend similar to CacheAccessor and not require a Dispatcher and unsafeRun

[yisraelU]

this would be a breaking change as it adds additional parameters.
I dont think TxExecutor is the right place for this, it is meant for Redis transactions

[gvolpe]

I would add that Dispatcher is not meant to be used as a typeclass, i.e. it should be passed explicitly

[yisraelU]

In general , I don't like Lettuce's implementation that forces a separate interface for cached values vs uncached.
I'd prefer to see something like injecting a CacheAccessor into the RedisClient creation , and allowing the internals to understand when a command is cacheable or not .

[aicodeguard]

Code Review – Key Findings

Summary:
The introduction of ClientSideCaching exposes a critical concurrency risk by bridging async effects into synchronous Lettuce callbacks using unsafeRunSync. This pattern, when executed on Lettuce's Netty EventLoop threads, poses a high risk of blocking I/O operations, leading to system instability or deadlocks.

Issues

1. [Bug] Blocking Netty EventLoop via unsafeRunSync
   • File: modules/core/src/main/scala/dev/profunktor/redis4cats/caching/ClientSideCaching.scala
   • Lines: 41-43
   • Details: The JCacheAccessor implementation calls redisExecutor.unsafeRun (which delegates to dispatcher.unsafeRunSync) inside get, put, and evict. Lettuce invokes these methods on its EventLoop threads. Blocking these threads prevents the client from processing any network I/O, heartbeats, or other command responses.
   • Fix:
     • Change CacheAccessor[F, K, V] to a synchronous interface (e.g., CacheAccessor[K, V]) to reflect the constraints of the underlying Lettuce API.
     • Alternatively, if F must be used, ensure that the provided implementation is strictly non-blocking (e.g., wrapping a ConcurrentHashMap) and document clearly that async operations (context shifts, I/O) are forbidden in this context.