Allow InMemoryRedis (L1+L2) without broadcast, for backends without full Redis Streams read support

[andreialionte]

Problem

AddInMemoryRedis() unconditionally wires up cross-node L1 invalidation via Redis Streams. There is currently no documented way to use the InMemoryRedis provider's L1+L2 tiering without this broadcast mechanism. Against Redis-compatible backends whose Streams support doesn't (yet) cover the consumer-group read side such as Microsoft Garnet, a RESP-compatible cache-store from Microsoft Research, not a fork of Redis this produces a continuous error loop as soon as the provider is used.

Environment

• Cache store: Microsoft Garnet (RESP-compatible)
• Provider: InMemoryRedis

Steps to reproduce

builder.Services.AddCaching(builder.Configuration.GetSection("Caching"), cachingBuilder =>
    cachingBuilder
        .AddRedisConnection(connectionOptions =>
        {
            connectionOptions.ConnectionString = redisConnectionString; // pointed at Garnet
            connectionOptions.AbortOnConnectFail = false;
            connectionOptions.WarmUpOnStart = false;
        })
        .AddRedis()
        .AddInMemoryRedis()
        .AddMemory()
        .AddLocalLock()
        .AddRedisDistributedLock()
        .AddResilienceStrategies()
        ,
    options => { /* ... */ });

_cache = cacheFactory.CreateCache("InMemoryRedis");

Observed behavior

Once "InMemoryRedis" is requested via CreateCache, the following error repeats continuously (roughly every 250ms):

fail: UiPath.Caching.Broadcast.Redis.RedisStreamsTopic
Fetch events loop error
StackExchange.Redis.RedisServerException: ERR unknown command
at UiPath.Caching.Broadcast.Redis.RedisStreamSubjectWriter1.FetchBatch() at UiPath.Caching.Broadcast.Redis.RedisStreamSubjectWriter1.FetchLoop()

Commenting out .AddBroadcast() in the builder chain has no effect on this behavior. Per concepts.md, AddInMemoryRedis() wires broadcast internally regardless of whether .AddBroadcast() is called this isn't evident from the builder API itself, and the presence of .AddBroadcast() as a separate chainable method reasonably suggests it controls broadcast for all providers, including InMemoryRedis.

Impact

There is currently no way to use L1+L2 tiering against a backend without full Streams read support. The only available workaround is to request the plain Redis provider instead, which forgoes the in-process L1 tier entirely a real cost even for single-node deployments, where cross-node invalidation provides no benefit in the first place.

Separately, on a Dragonfly backend, we hit a related-but-distinct issue: StackExchange.Redis's automatic CLUSTER topology probe (issued against any server on connect) returned an announced endpoint different from our configured one, causing an unrelated reconnect loop. Not a UiPath.Caching issue, but noted here as another example of assumptions that don't hold uniformly across Redis-compatible backends.

Garnet's Streams support (for context)

Worth noting: Garnet does have some Streams support now (writes/ranges), but it doesn't yet support the read/consumer-group commands (XREAD/XREADGROUP) that UiPath.Caching's broadcast loop actually depends on so this isn't a bug on Garnet's side either, just a gap between what the two projects currently support. (Tracked upstream at microsoft/garnet#1379, if useful.)

Proposed solution

1. An option to construct InMemoryRedis with broadcast disabled, e.g.:

.AddInMemoryRedis(options => options.BroadcastEnable = false)

so L1+L2 tiering can be used independent of the backend's Streams read support, and independent of whether cross-node invalidation is even needed (e.g. single-node deployments).

2. Documentation clarifying that .AddBroadcast() does not affect InMemoryRedis behavior, so others don't spend time on the same assumption.

Alternatives considered

• Plain Redis provider (current workaround) avoids the error, but forgoes in-process (L1) caching entirely, even in cases (single-node, or backends where Streams reads simply aren't available yet) where L1 would otherwise be safe and beneficial to use.
• Waiting on upstream Garnet Streams support doesn't help today, and doesn't address the single-node case where broadcast isn't needed regardless of backend capability.

[cosmin-staicu]

Two of the three asks already work today.

Garnet has PUBLISH/SUBSCRIBE; it's only XREADGROUP that's missing. The Pub/Sub transport is already in the library, just off by default:

"Caching": {
  "DefaultTopic": "RedisPubSub",
  "Broadcast": {
    "RedisPubSub":  { "Enabled": true },
    "RedisStreams": { "Enabled": false }
  }
}

All three lines matter. DefaultTopic because TopicFactory resolves by provider name rather than "whichever provider is enabled", so leaving it on RedisStreams drops your invalidations silently. RedisStreams:Enabled: false because otherwise RedisStreamHealthMaintainer still starts and runs SCAN/XINFO against Garnet. This keeps L1+L2 and cross-node invalidation, so it beats turning broadcast off. The tradeoff is at-most-once with no replay: a pod that restarts misses whatever arrived while it was down.

To turn broadcast off entirely, "Caching": { "BroadcastEnabled": false } already does it. Everything falls back to NullTopicFactory and InMemoryRedis runs as plain L1+L2.

Both are covered in docs/how-to/broadcast.md, which also states that AddInMemoryRedis() wires broadcast internally and that a code-only AddBroadcast(enabled: false) doesn't stick. You went to concepts.md, which was the reasonable place to look and didn't point onward. That's fixed.

#119 handles the rest:

• The fetch loop no longer hammers a server without XREADGROUP. One Critical log naming the remedies, then retries at 30s instead of 250ms, and it recovers by itself if the connection later reaches a server that supports the command.
• CacheOptions.BroadcastEnabled now actually disables broadcast. It was read only by RedisStreamHealthMaintainer, so setting it in code stopped the maintainer while the fetch loop kept running.
• New InMemoryRedisCacheOptions.BroadcastEnable, default true, which is your ask chore(deps): bump actions/upload-artifact from 5 to 7 #1 at provider scope.

On the Dragonfly CLUSTER probe: agreed, that's StackExchange.Redis rather than us.