RedisMetrics and AsyncRedisProvider both ship, but nothing joins them: every consumer writes the same dishka provider

[AlexeyShalaev]

redis-client-kit ships AsyncRedisProvider and it ships RedisMetrics, but nothing that
joins them, so every consumer writes the same provider. sqlalchemy-foundation-kit ships
exactly that join for Postgres — contrib.di.metrics.PrometheusPostgresMetricsProvider —
and the two kits are otherwise the same shape.

What we carry

class PrometheusRedisMetricsProvider(BaseMetricsProvider):
    @provide
    def get_metrics(
        self,
        metrics: PrometheusMetricsSettingsProtocol,
        default_prefix: str | None,
        redis: RedisMetricsSettingsProtocol | None = None,
    ) -> RedisMetrics | None:
        if redis is None or not redis.metrics_enabled:
            return None
        return RedisMetrics(prefix=_infra_metrics_prefix(default_prefix))

    @provide
    def get_metrics_protocol(self, metrics: RedisMetrics | None) -> RedisMetricsProtocol | None:
        return metrics

Everything it reads is yours: BaseRedisSettings.metrics_enabled (default False) is the
gate, RedisMetrics is the collector, RedisMetricsProtocol is the key
AsyncRedisProvider consumes. The only thing we contribute is the wiring, and it is the
same wiring for every consumer.

Registered next to yours, it reads:

make_async_container(
    AsyncRedisProvider(provide_default_metrics=False),
    PrometheusRedisMetricsProvider(),   # ours, and it should be yours
    ...
)

The provide_default_metrics=False is the tell: AsyncRedisProvider already has an opinion
about who provides the metrics seam, and the alternative to its None is a provider the kit
does not ship.

The second half: the collector cannot be built twice

>>> RedisMetrics(prefix=None); RedisMetrics(prefix=None)
ValueError: Duplicated timeseries in CollectorRegistry: {'redis_pool_size', ...}

A container rebuilt per test — which is what a test suite does — asks for the collector
again and gets that. grpc-client-kit solved this with metrics.get_grpc_client_metrics():
one instance per prefix on the default registry, documented as "so a container rebuilt per
test never asks Prometheus to register the same series twice". A
get_redis_metrics(prefix=None) of the same shape would make the provider safe to register
in a fixture, and is worth having on its own even for consumers who never use dishka.

What we would use

redis_client_kit.providers.PrometheusRedisMetricsProvider, gated on
BaseRedisSettings.metrics_enabled, sourcing the collector from a cached getter — the
sqlalchemy-foundation-kit layout, since that is the one consumers already know. Then our
provider goes and dishka-providers loses another quarter of what is left of it.

Context: ai-ops, 11 services registering this provider. We have just deleted our postgres
and gRPC copies because those kits shipped theirs; Redis, inbox/outbox and idempotency are
the three left, and they are the same issue three times
(bedrock-python/omni-box, bedrock-python/idempotency-kit).

[AlexeyShalaev]

Taking this. One PR, two feat: commits — the provider and the getter.

The provider is redis_client_kit.providers.PrometheusRedisMetricsProvider(*, prefix=None), next to AsyncRedisProvider and behind the same [providers] extra. It requests RedisSettingsProtocol — the key your container already provides — and provides RedisMetricsProtocol | None in APP scope: get_redis_metrics(prefix) when settings.metrics_enabled, None otherwise, which is exactly what AsyncRedisProvider reads through provide_default_metrics=False. That moves metrics_enabled from "declared and never read" onto the protocol: RedisSettingsProtocol gains metrics_enabled: bool. BaseRedisSettings has had the field from the start, so nothing changes on your side; a hand-written settings class needs the one attribute, and mypy will say so.

I did not take your copy's PrometheusMetricsSettingsProtocol + default_prefix pair. Those are keys from your application, and a kit provider that requests them makes every consumer provide them. The prefix is a constructor argument instead, the way grpc-client-kit's provider takes it.

The getter is redis_client_kit.metrics.get_redis_metrics(prefix=None), exported next to RedisMetrics: one instance per prefix on the default registry, cached, so the second container in a test session gets the first one's collector back instead of the duplicate-timeseries error. RedisMetrics(prefix=None) twice will still raise — that is Prometheus refusing to register a name twice, and the getter is the answer rather than a change to the class.

With metrics_enabled on and the metrics extra missing, resolving the collector raises the ImportError naming the extra, the same one import redis_client_kit.metrics raises. Loud rather than a warning and None, because that is how every other extra in this kit fails.

Tests: your container with metrics on and off, the collector actually reaching the client (InstrumentedRedis), and two containers built in a row. Docs: the advanced guide, the agents page, the settings tables.

[AlexeyShalaev]

#37 has both halves.

redis_client_kit.providers.PrometheusRedisMetricsProvider(*, prefix=None) is the provider. It requests RedisSettingsProtocol — the key you already provide — and provides RedisMetricsProtocol | None as get_redis_metrics(prefix) when settings.metrics_enabled and None otherwise, APP scope. Your container becomes

make_async_container(
    AsyncRedisProvider(provide_default_metrics=False),
    PrometheusRedisMetricsProvider(),
    ...
)

and the kit's own copy of your class can go. The two differences from what you carry: the prefix is a constructor argument rather than a default_prefix key from your container, and RedisSettingsProtocol now declares metrics_enabled: bool — BaseRedisSettings always had it, so nothing to change on your side unless one of the eleven services hand-writes its settings class.

redis_client_kit.metrics.get_redis_metrics(prefix=None) is the getter: one RedisMetrics per prefix on the default registry, handed back on every later call, so two containers in a row get the same collector. RedisMetrics(prefix=None) twice still raises — that is Prometheus refusing to register a name twice, and the class is unchanged — so a fixture should ask the getter, or just register the provider and let it.

Ran your scenario in a fresh process against the branch:

get_redis_metrics() twice is the same object: True
metrics_enabled=False: client=Redis, metrics=NoneType
metrics_enabled=True: client=InstrumentedRedis, metrics=RedisMetrics
metrics_enabled=True: client=InstrumentedRedis, metrics=RedisMetrics
two containers in a row hand out the same collector: True
and it is get_redis_metrics(): True
RedisMetrics(prefix=None) by hand still raises: Duplicated timeseries in CollectorRegistry: {'redis_pool_s ...

One thing to know: with metrics_enabled on and the metrics extra not installed, resolving the collector raises ImportError naming the extra rather than quietly handing out None. Lands in the next minor.