Can't consume bulk keys from Invalidate channel

[atamanber]

Hi.

To implement client-side caching, I have subscribed to "redis:invalidate" channel in my application as described in the article, and the application can consume invalidated messages successfully when another connection updates a key. Below is how my application connects to channel:

IConnectionMultiplexer _connection; //Initialized at startup. 
RedisChannel _invalidationChannel = new("__redis__:invalidate", RedisChannel.PatternMode.Auto);
ISubscriber subscriber = _connection.GetSubscriber()
subscriber.Subscribe(_invalidationChannel)?.OnMessage(OnMessage);
_connectionFacade.Execute("CLIENT", "TRACKING", "on", "REDIRECT", connectionId, "BCAST", "NOLOOP");

private void OnMessage(ChannelMessage message)
{
    try
    {
        _logger.LogDebug(message.Message.ToString());
    }
    catch(Exception ex)
    {
        _logger.LogError(ex, "Error RedisInvalidator.OnMessage: {message}", ex.Message);
    }
}

However, if I use bulk commands like MSET, MDEL or transactional update from another application with multiple variables, StackExchange.Redis doesn't consume any invalidation messages. Redis server is able to send a single invalidation message for multiple keys, which I tested by subscribing by terminal. If I apply MSET command with one key-value pair, I can consume it in the application however if I apply it with multiple key-value pairs then I can't consume it. Also no exceptions are thrown from the library.

As shown in below, for testing purposes I opened two terminals, left one was listening the invalidation channel, and right one was updating the Redis. First, I applied "MSET test 123"(right terminal) and this one is consumed by left-hand terminal and by my application as well. However when I applied "MSET test 123 test2 123"(right terminal), it was only consumed by left-hand terminal. My application couldn't consume it. Be aware that invalidation message consist list of keys that are invalidated when there is a multiple invalidation.

[mgravell]

well shoot, I guess I forgot to checkout -b!

long story short: we don't currently endorse this usage, and client tracking is something we want to add properly later; however, I do agree that the pub/sub itself should work, hence the above which I'll put through review in a moment; local testing:

[mgravell]

emphasis: it is our intention to add a proper write-thru cache with use of server-assisted caching; if you want to do something with that manually today: fine, just: hopefully we can make it cleaner later; in particular, I'd be worried here about connection lifetime and cluster semantics, but: that's your problem :)

[atamanber]

Hey! Thanks for the quick support. I'll will keep in the mind the connection lifetime until you add that feature to the library.

[atamanber]

Finally, do you guys have an estimated/scheduled release date for next version(including this fix)?

[NickCraver]

@atamanber It's available on MyGet now, but we'll likely be on NuGet within a few weeks usually - working on a few things we'd like to have in the next one instructing people to upgrade for goodies.