The dishka provider asks for Redis, redis-client-kit provides Redis | RedisCluster: the container never builds

[AlexeyShalaev]

The shipped dishka provider asks for redis.asyncio.Redis, redis-client-kit provides
Redis | RedisCluster — a container registering both never builds.

What happens

idempotency_kit.dishka.aio.redis requests the concrete client:

from redis.asyncio import Redis as AsyncRedisClient
...
def get_repository(self, redis: AsyncRedisClient, ...) -> AsyncIdempotencyRepository: ...

redis_client_kit.providers.AsyncRedisProvider provides the union its own alias names:

>>> from redis_client_kit import AsyncRedisClient
>>> AsyncRedisClient
redis.asyncio.client.Redis | redis.asyncio.cluster.RedisCluster

dishka resolves by exact key, so the two do not meet:

make_async_container(
    AsyncRedisProvider(),              # provides Redis | RedisCluster
    AsyncRedisIdempotencyProvider(),   # requests Redis
    ...
)
# dishka.exceptions.GraphMissingFactoryError:
#   Cannot find factory for (Redis, component=''). It is missing or has invalid scope.

No Redis server is needed to reproduce — it fails at container construction.

Why it matters

These are the two libraries in the ecosystem that both talk to Redis and both ship dishka providers,
so a service using idempotency with the kit's Redis client is the expected combination, and it is
exactly the one that cannot be wired from the shipped pieces. The failure is at least loud, but the
only ways out are to keep a private provider (what we do), or to register a bridge that claims a
RedisCluster is a Redis, which is a lie the day someone enables cluster mode.

We have kept a local Redis-plus-idempotency provider pair in a 14-service monorepo for this reason
alone; every other provider in that package has been replaced by a shipped one.

What would help

Whatever makes the two keys meet without a consumer-side adapter. Options we can see:

• accept the union (or a structural protocol covering the commands the repository actually issues),
  so a cluster client is either genuinely supported or rejected with a clear message;
• state that the repository requires a non-cluster Redis and provide a supported way to narrow
  the union, so the cast happens once, here, with the check attached;
• agree a shared alias between the two libraries.

The design call is yours — a cluster-mode Redis may well not be supportable by a repository that
uses multi-key operations, and if so that constraint is worth expressing in the type rather than
discovered at runtime.

Cross-reference: redis-client-kit owns the other half of this key, redis_client_kit.providers.

Versions

idempotency-kit 0.3.0, redis-client-kit 0.2.0, dishka 1.9.1, redis 7.4.0, CPython 3.14.

[AlexeyShalaev]

Reproduced as described, no server: AsyncRedisProvider(check_health_on_startup=False) from redis-client-kit 0.2.0 next to AsyncRedisIdempotencyProvider() fails inside make_async_container with Cannot find factory for (Redis, component='').

The design question was whether the repository can honestly take a cluster client, so I went through every command it issues. get, save, replace and delete are single-key. save_many is a pipeline(transaction=False), which the async RedisCluster accepts and routes per key. delete_many and the expired-key cleanup send DEL with many keys, which redis-py's cluster client already splits per slot (AsyncClusterMultiKeyCommands.delete). The one problem is get_many: it sends a single MGET, and RedisCluster._determine_slot raises RedisClusterException("MGET - all keys must map to the same key slot") as soon as the keys land in different slots, which they do (idempotency:orders.create:a, :b, :c hash to 13368, 1115 and 5242). So the "fully compatible with Redis Cluster" line in the user guide is false today for exactly one method, and redis-py has the counterpart, mget_nonatomic: one MGET per slot, values returned in input order.

The plan is therefore to make the union true rather than narrow it. RedisAsyncIdempotencyRepository takes Redis | RedisCluster and get_many uses mget_nonatomic when the client is a RedisCluster; AsyncRedisIdempotencyProvider.get_repository requests Redis | RedisCluster. That is the dishka key redis-client-kit provides: types.UnionType compares structurally, and DependencyKey(Redis | RedisCluster) built here equals the one built from redis_client_kit.AsyncRedisClient, so no shared alias and no dependency on redis-client-kit is needed, and nothing changes on that side. The test group does gain redis-client-kit[providers,settings], so the test for your case is your wiring with the real AsyncRedisProvider, not a look-alike.

The cost: this breaks anyone whose own provider provides redis.asyncio.Redis exactly, which is what the docs told them to write. dishka matches keys exactly, so their container fails at construction with the same GraphMissingFactoryError, now naming Redis | RedisCluster; the migration is that one annotation. I'll ship it as fix!: with the migration in the changelog note and the docs example. I considered keeping Redis as the default behind a client_type= constructor argument, but that leaves the shipped pieces not composing by default, which is the complaint. If you'd rather not break -> Redis providers at all, say so and I'll do the argument instead.

Rejected: a protocol over the commands the repository uses, because dishka would still need exactly that key provided, so it does not meet redis-client-kit's union without an adapter; and the narrowing helper, because cluster is supportable, so refusing it in the type would be the lie in the other direction. The sync side has nothing to mirror: idempotency-kit is async only and redis-client-kit ships no sync provider.

[AlexeyShalaev]

Shipped in #33. AsyncRedisIdempotencyProvider now asks for redis.asyncio.Redis | RedisCluster, which is the key redis_client_kit.AsyncRedisClient names: types.UnionType compares structurally, so the two meet without a shared alias or a dependency between the libraries, and nothing changes in redis-client-kit. Your wiring — make_async_container(AsyncRedisProvider(), ..., AsyncRedisIdempotencyProvider(), ...) — is now a unit test in this repo against the real provider (redis-client-kit is in the test group), and the script from the report prints built: RedisAsyncIdempotencyRepository client: Redis on the branch where master printed Cannot find factory for (Redis, component='').

On the cluster question: the repository is single-key everywhere except get_many, and that one sent a single MGET, which a cluster refuses as soon as the keys span hash slots, which they do. So the docs were wrong rather than the type. On a RedisCluster, get_many now goes through mget_nonatomic, one MGET per slot, so cluster mode is genuinely supported and the union is honest rather than a cast.

On your side, the private Redis-plus-idempotency provider pair can go. When you drop it, make sure nothing you keep provides -> Redis for this container: Dishka matches keys exactly, so that annotation is a different key from the union and the container fails at construction with the same GraphMissingFactoryError, now naming Redis | RedisCluster. That is the breaking part for anyone who followed the old docs example, and the fix is the annotation. It goes out as 0.4.0 once merged.