feat: add SetOnInvalidations to DedicatedClient

[jinbum-kim]

Closes #927

pipe.handlePush currently intercepts RESP3 invalidate push messages, so DedicatedClient users cannot receive client-side caching invalidations on the same dedicated connection they use for CLIENT TRACKING.

Instead, they currently need a separate client configured with ClientOption.OnInvalidations.

This PR adds SetOnInvalidations to DedicatedClient so invalidation messages can be handled on that same dedicated connection.

Changes:

• add SetOnInvalidations to DedicatedClient
• implement it for both standalone and cluster dedicated clients
• preserve existing PubSubHooks and replace only the invalidation callback
• forward RESP3 invalidate push messages to the dedicated invalidation hook path
• send CLIENT TRACKING OFF when a dedicated connection is returned to the pool, so no tracking state is retained across reuse
• update wrappers/mocks and add tests for the new dedicated invalidation hook path

Example:

dc, cancel := client.Dedicate()
defer cancel()

ch := dc.SetOnInvalidations(func(messages []rueidis.RedisMessage) {
    // handle invalidations
})

dc.Do(ctx, dc.B().ClientTracking().On().Prefix().Prefix(prefix).Bcast().Build())
<-ch

---

Note

Medium Risk
Adds a new callback path for RESP3 invalidate push messages and changes dedicated-connection pooling to issue CLIENT TRACKING OFF on reuse, which could affect client-side caching behavior if misused. Scope is contained to DedicatedClient/pubsub hook plumbing and has test coverage.

Overview
Adds DedicatedClient.SetOnInvalidations(fn) to let dedicated standalone and cluster clients receive RESP3 invalidate push messages on the same connection used for CLIENT TRACKING, without overwriting existing PubSubHooks.

Plumbs invalidation delivery through PubSubHooks (new onInvalidations field), adds wire.GetPubSubHooks(), and updates pipe.handlePush to fan out invalidate events to both the existing ClientOption callback and the dedicated hook path.

Hardens pooling semantics: when a dedicated wire is returned to the pool, mux.Store clears hooks/subscriptions and, if invalidation hooks were installed, sends CLIENT TRACKING OFF to avoid leaking tracking state across reuse. Updates mocks/wrappers and adds targeted tests for hook preservation, reset behavior, and tracking-off on store.

^{Reviewed by Cursor Bugbot for commit e870346. Bugbot is set up for automated code reviews on this repo. Configure here.}

[rueian]

Hi @jinbum-kim,

I think using this is probably wrong because we will never turn client tracking on again, right?

[jinbum-kim]

Yes. I've removed CLIENT TRACKING OFF from CleanSubscriptions and dropped ClientTrackingOffCmd from this PR.

Should we instead send CLIENT TRACKING OFF when the invalidation hook is explicitly cleared, or leave that entirely to the caller?

[rueian]

Hmm, this is a bit tough.

After a second thought, doing CLIENT TRACKING OFF automatically when the connection is returned to the pool might actually be a correct move because, for the dedicated pool, neither users nor we rely on client tracking in the pool. Client tracking is essentially off in the pool in the first place.

[jinbum-kim]

Yeah, I think this is a bit tricky too 👀
Let me think about it a bit more and get back to you.

[jinbum-kim]

Hi, It seems more appropriate to clean it up when the dedicated connection is returned to the pool, so that no tracking state is retained across reuse. I'll revise the PR in this way.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

[rueian]

Let's do this only when onInvalidations was set on the hooks.

[jinbum-kim]

Should I also keep the w.Version() >= 6 guard, or is checking onInvalidations != nil alone sufficient?

hasOnInvalidations := w.GetPubSubHooks().onInvalidations != nil
...
if hasOnInvalidations (``&& w.Version() >= `6`) {
		w.Do(context.Background(), cmds.ClientTrackingOffCmd)
	}

[jinbum-kim]

I've updated it so that it only applies when onInvalidations is set. If you have any further suggestions, please let me know.

[rueian]

What will happen if we don't save this orig? Can we remove it?

[rueian]

Hi @jinbum-kim, is it possible to remove this orig?

[jinbum-kim]

Hi @rueian, Apologies for the delayed response. I recently started a new job, so my available time has been a bit limited 😅

I think orig is still needed.

SetPubSubHooks canonicalizes nil OnMessage / OnSubscription into internal no-op handlers, and SetOnInvalidations now does a read-modify-write through GetPubSubHooks():

hooks := c.wire.GetPubSubHooks()
hooks.onInvalidations = fn
return c.SetPubSubHooks(hooks)

(in this commit)

SetPubSubHooks checks isZero() before canonicalization, so this works only if GetPubSubHooks() returns the original user-intent shape.

If GetPubSubHooks() returned the canonicalized form, then clearing fn would no longer reset back to zero when invalidations was the only originally-installed hook, because OnMessage / OnSubscription would already be non-nil.

That would break the documented behavior of SetOnInvalidations, which returns nil when clearing fn leaves no hooks installed.

So unless we preserve the original nil-ness some other way, I think we should keep orig.

[rueian]

Thanks, I just removed the canonicalization.

[jinbum-kim]

Thanks! Are there any additional points I should look into?

[rueian]

Thanks for the contribution! @jinbum-kim

[jinbum-kim]

My pleasure 😀 @rueian
If there's anything else I can help with, feel free to tag me anytime.