chore: bump github.com/redis/go-redis/v9 from 9.21.0 to 9.22.0 in the go group

[dependabot]

Bumps the go group with 1 update: github.com/redis/go-redis/v9.

Updates github.com/redis/go-redis/v9 from 9.21.0 to 9.22.0

Release notes

Sourced from github.com/redis/go-redis/v9's releases.

9.22.0

This is a minor release introducing two flagship (experimental) features — client-side caching and automatic pipelining — alongside support for Redis 8.10, new commands, and a large batch of stability and parser-robustness fixes. It consolidates everything shipped in 9.22.0-beta.1, so the notes below cover the full 9.21.0 → 9.22.0 upgrade.

⚠️ Two changes to be aware of when upgrading from 9.21.0:

• Default configuration values changed (#3918): read/write timeouts, retry backoff, cluster state reload interval, and TCP keep-alive defaults are now aligned with the cross-SDK configuration proposal (see the highlight below). Explicitly configured values are unaffected.
• WaitAOF return type corrected (#3888): WaitAOF now returns *IntSliceCmd, matching the two-integer reply of WAITAOF (previously *IntCmd, which failed to parse the reply at runtime). Code referencing the old return type needs a one-line update.

🚀 Highlights

Client-Side Caching (Experimental)

The standalone Client gains server-assisted client-side caching built on RESP3 CLIENT TRACKING. Enable it by setting ClientSideCacheConfig in Options (or supply your own cache via ClientSideCache — e.g. to share one cache across clients). Cacheable read results are served from a local in-process cache and invalidated automatically when the server reports a change, cutting round trips for read-heavy workloads.

The invalidation architecture is selected by ClientSideCacheStrategy; the default (and currently only) strategy is CSCStrategySharedTracking: one shared cache, every pool connection runs plain CLIENT TRACKING ON, and a background drainer applies buffered invalidations — portable (no BCAST) and consistent with the other Redis client libraries. Requirements and guardrails: RESP3 (Protocol: 3), standalone client, DB 0 only; commands that would change the connection identity (SELECT, AUTH, ...) are rejected while caching is enabled, and CSC is disabled when a credentials provider is set (fixed Username/Password work and are namespaced). See the README's client-side caching section and the runnable example.

Experimental: the API may change in a minor release.

(#3941) by @​ofekshenawa

Automatic Pipelining (Experimental)

AutoPipeliner is a background batcher that coalesces commands from many concurrent goroutines into Redis pipelines, multiplying throughput without any manual pipeline management. It comes in two faces, available on Client and ClusterClient (and configurable via Options.AutoPipelineOptions / UniversalOptions.AutoPipelineOptions):

• AutoPipeline() — the blocking face: a drop-in Cmdable where each call blocks until executed, exactly like a plain client, while concurrent callers' commands batch together under the hood (measured locally over loopback: ~1M+ SET/sec vs ~100k unpipelined; indicative, not a guarantee). Per-goroutine command order is preserved.
• AsyncAutoPipeline() — the deferred face: command calls return immediately and every typed result accessor (Val/Result/Err/...) blocks until the command has executed. Submit a window of commands, then read the results, to keep pipelines deep (~2–3M SET/sec locally; indicative).

AutoPipelineOptions controls batching: MaxBatchSize (soft target, default 200; the blocking face's preset uses 300), MaxBatchBytes (approximate payload cap so huge values flush as several bounded writes), MaxFlushDelay with optional AdaptiveDelay (delay scales down as the queue fills), and MaxConcurrentBatches (default 1 = a single ordered batch stream; raising it requires Unordered: true, so ordering is never lost by accident — Validate() rejects the combination otherwise). A usage tour and throughput comparison live in https://github.com/redis/go-redis/blob/HEAD/example/autopipeline.

Experimental: the API may change in a future release — pin your go-redis version if you adopt it.

(#3942) by @​ndyakov, with help from @​cxljs

Redis 8.10 Support

This release adds support for Redis 8.10. The README's supported-versions list now includes Redis 8.10, and CI runs the full suite against the redislabs/client-libs-test:8.10.0 image by default (#3920, #3940).

Coverage for the new commands and options that ship with Redis 8.10:

• HIMPORT (#3919) — bulk hash import via server-side fieldsets, exposed as HImportPrepare, HImportSet, HImportDiscard, and HImportDiscardAll. Fieldsets are session state scoped to a single physical connection, which does not mix well with connection pooling — so the client keeps a versioned fieldset registry and lazily replays the PREPARE on whichever pooled connection executes a SET that needs it, at most once per connection, with no extra round trip (the PREPARE is injected into the same write as the SET).
• LMOVEM / BLMOVEM (#3913) — move multiple elements between lists in one call.
• SUNIONCARD / SDIFFCARD (#3897) — cardinality of set union/difference without materializing the result.
• XREAD / XREADGROUP MAXCOUNT and MAXSIZE (#3898) — bound how much data a stream read returns.
• TS.READ (#3896), TS.QUERYLABELS (#3926), TS.NRANGE / TS.NREVRANGE (#3870) with multiple aggregators per key (#3937), and EXCLUDEEMPTY on TS.MRANGE / TS.MREVRANGE (#3912) — new time-series query surface.
• FT.ALIASLIST (#3925), COLLECT reducer for FT.AGGREGATE (#3886), RERANK on HNSW vector fields in FT.CREATE (#3927), and FT.HYBRID timeout warnings (#3911) — search coverage.

Cross-SDK Aligned Defaults

Default configuration values now follow the cross-SDK configuration proposal shared by all Redis client libraries (#3918):

... (truncated)

Changelog

Sourced from github.com/redis/go-redis/v9's changelog.

9.22.0 (2026-08-03)

This is a minor release introducing two flagship (experimental) features — client-side caching and automatic pipelining — alongside support for Redis 8.10, new commands, and a large batch of stability and parser-robustness fixes. It consolidates everything shipped in 9.22.0-beta.1, so the notes below cover the full 9.21.0 → 9.22.0 upgrade.

⚠️ Two changes to be aware of when upgrading from 9.21.0:

• Default configuration values changed (#3918): read/write timeouts, retry backoff, cluster state reload interval, and TCP keep-alive defaults are now aligned with the cross-SDK configuration proposal (see the highlight below). Explicitly configured values are unaffected.
• WaitAOF return type corrected (#3888): WaitAOF now returns *IntSliceCmd, matching the two-integer reply of WAITAOF (previously *IntCmd, which failed to parse the reply at runtime). Code referencing the old return type needs a one-line update.

🚀 Highlights

Client-Side Caching (Experimental)

The standalone Client gains server-assisted client-side caching built on RESP3 CLIENT TRACKING. Enable it by setting ClientSideCacheConfig in Options (or supply your own cache via ClientSideCache — e.g. to share one cache across clients). Cacheable read results are served from a local in-process cache and invalidated automatically when the server reports a change, cutting round trips for read-heavy workloads.

The invalidation architecture is selected by ClientSideCacheStrategy; the default (and currently only) strategy is CSCStrategySharedTracking: one shared cache, every pool connection runs plain CLIENT TRACKING ON, and a background drainer applies buffered invalidations — portable (no BCAST) and consistent with the other Redis client libraries. Requirements and guardrails: RESP3 (Protocol: 3), standalone client, DB 0 only; commands that would change the connection identity (SELECT, AUTH, ...) are rejected while caching is enabled, and CSC is disabled when a credentials provider is set (fixed Username/Password work and are namespaced). See the README's client-side caching section and the runnable example.

Experimental: the API may change in a minor release.

(#3941) by @​ofekshenawa

Automatic Pipelining (Experimental)

AutoPipeliner is a background batcher that coalesces commands from many concurrent goroutines into Redis pipelines, multiplying throughput without any manual pipeline management. It comes in two faces, available on Client and ClusterClient (and configurable via Options.AutoPipelineOptions / UniversalOptions.AutoPipelineOptions):

• AutoPipeline() — the blocking face: a drop-in Cmdable where each call blocks until executed, exactly like a plain client, while concurrent callers' commands batch together under the hood (measured locally over loopback: ~1M+ SET/sec vs ~100k unpipelined; indicative, not a guarantee). Per-goroutine command order is preserved.
• AsyncAutoPipeline() — the deferred face: command calls return immediately and every typed result accessor (Val/Result/Err/...) blocks until the command has executed. Submit a window of commands, then read the results, to keep pipelines deep (~2–3M SET/sec locally; indicative).

AutoPipelineOptions controls batching: MaxBatchSize (soft target, default 200; the blocking face's preset uses 300), MaxBatchBytes (approximate payload cap so huge values flush as several bounded writes), MaxFlushDelay with optional AdaptiveDelay (delay scales down as the queue fills), and MaxConcurrentBatches (default 1 = a single ordered batch stream; raising it requires Unordered: true, so ordering is never lost by accident — Validate() rejects the combination otherwise). A usage tour and throughput comparison live in https://github.com/redis/go-redis/blob/master/example/autopipeline.

Experimental: the API may change in a future release — pin your go-redis version if you adopt it.

(#3942) by @​ndyakov, with help from @​cxljs

Redis 8.10 Support

This release adds support for Redis 8.10. The README's supported-versions list now includes Redis 8.10, and CI runs the full suite against the redislabs/client-libs-test:8.10.0 image by default (#3920, #3940).

Coverage for the new commands and options that ship with Redis 8.10:

• HIMPORT (#3919) — bulk hash import via server-side fieldsets, exposed as HImportPrepare, HImportSet, HImportDiscard, and HImportDiscardAll. Fieldsets are session state scoped to a single physical connection, which does not mix well with connection pooling — so the client keeps a versioned fieldset registry and lazily replays the PREPARE on whichever pooled connection executes a SET that needs it, at most once per connection, with no extra round trip (the PREPARE is injected into the same write as the SET).
• LMOVEM / BLMOVEM (#3913) — move multiple elements between lists in one call.
• SUNIONCARD / SDIFFCARD (#3897) — cardinality of set union/difference without materializing the result.
• XREAD / XREADGROUP MAXCOUNT and MAXSIZE (#3898) — bound how much data a stream read returns.
• TS.READ (#3896), TS.QUERYLABELS (#3926), TS.NRANGE / TS.NREVRANGE (#3870) with multiple aggregators per key (#3937), and EXCLUDEEMPTY on TS.MRANGE / TS.MREVRANGE (#3912) — new time-series query surface.
• FT.ALIASLIST (#3925), COLLECT reducer for FT.AGGREGATE (#3886), RERANK on HNSW vector fields in FT.CREATE (#3927), and FT.HYBRID timeout warnings (#3911) — search coverage.

Cross-SDK Aligned Defaults

Default configuration values now follow the cross-SDK configuration proposal shared by all Redis client libraries (#3918):

... (truncated)

Commits

• c7f59a2 chore(release): prepare 9.22.0 (#3947)
• c994cfc feat(autopipeline): automatic command pipelining (#3942)
• 228b463 chore(deps): bump actions/stale from 10 to 11 (#3944)
• a6be850 feat(csc): add standalone client-side caching (#3941)
• 82b0213 chore(release): prepare 9.22.0-beta.1 (#3940)
• 8eb9583 fix(rediscmd): redact credential args in AppendCmd (#3939)
• 90fd088 chore(ci): point 8.10 testing at custom client-libs-test image (#3938)
• 93f961a feat(timeseries): support multiple aggregators per key in TS.NRANGE (#3937)
• 49e0041 feat(himport): HIMPORT command with lazy per-connection prepare (#3919)
• 3dd9675 fix(proto): peek push notification name without demanding 36 bytes (#3936)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[augmentcode]

🤖 Augment PR Summary

Summary: Bumps the direct Redis client dependency from go-redis/v9 9.21.0 to 9.22.0.
Technical note: The release adds Redis 8.10 support and experimental client caching/pipelining, while changing several default client timeout and retry settings.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 1 suggestion posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

go-redis v9.22.0 changes the default retry backoff to 10 ms / 1 s, but examples/stale-data-prevention/README.md:277-278 still documents 8 ms / 512 ms. Users relying on this operational guidance will receive incorrect retry timing.

Severity: low

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}