chore(deps): update dependency stackexchange.redis to v3

[thomhurst]

This PR contains the following updates:

Package	Type	Update	Change
StackExchange.Redis (source)	nuget	major	2.13.17 → 3.0.0

---

Release Notes

StackExchange/StackExchange.Redis (StackExchange.Redis)

v3.0.0

3.0.0 represents an overhaul of the internal IO logic, for both performance and stability reasons.

Intentionally, there are no API changes in this release; it is a direct mirror of 2.13.17, but with the new IO core.

What is the aim of the internals rewrite?

SE.Redis v2 made use of a few concepts internally:

• the "pipelines" IO layer from System.IO.Pipelines, via Pipelines.Sockets.Unoficial
• a DOM-based parser built on top of a custom arena allocator

v3 fundamentally revises these engineering decisions:

• IO and buffer control is taken back directly into the library, allowing for greater control of IO boundaries and the threading model
• the parser is re-written as a reader-based implementation

This allows for significant performance improvement, especially when processing large / complex results - for example, if we use the LRANGE_600 test from redis-benchmark (or resp-benchmark):

### classic SE.Redis 2.13.17.28173 ###
LRANGE_600:     7,579 requests per second
LRANGE_600:     7,554 requests per second
LRANGE_600:     7,284 requests per second
LRANGE_600:     7,158 requests per second
LRANGE_600:     7,174 requests per second

vs

### classic SE.Redis 3.0.0.11234 ###
LRANGE_600:     16,408 requests per second
LRANGE_600:     17,681 requests per second
LRANGE_600:     17,331 requests per second
LRANGE_600:     17,317 requests per second
LRANGE_600:     16,665 requests per second

(for tests with simpler results, like INCR, results of over 1M requests per second are achievable)

---

3.0 is the first part of a wave of planned IO work; 3.1 will revise the "write" part of the write loop, moving message serialization out of the critical serialized core of the multiplexer. All of this work is based on extensive prototyping and benchmarking, demonstrating that these approaches, when combined, provide significant throughput and stability improvements.

This release has undergone extensive testing. If you experience problems, please let us know!

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate.

[claude]

Code Review: Update StackExchange.Redis 2.13.17 → 3.0.0

This is a Renovate-generated major version bump. Here's my assessment:

Summary

The diff is minimal (2 lines) but the version bump is meaningful. However, the v3.0.0 release notes are explicit:

"Intentionally, there are no API changes in this release; it is a direct mirror of 2.13.17, but with the new IO core."

This makes the update low-risk from a compatibility standpoint. The internal IO layer was rewritten (replacing System.IO.Pipelines + arena allocator with a custom reader-based implementation), but the public API surface is unchanged.

API Compatibility

The project's Redis usage in the CloudShop example is limited to:

• ConnectionMultiplexer.ConnectAsync() — preserved
• IConnectionMultiplexer.GetDatabase() / DisposeAsync() — preserved
• IDatabase.StringGetAsync, StringSetAsync, KeyDeleteAsync — all preserved

No compatibility issues expected.

Performance Benefit

The release notes show approximately 2.2x throughput improvement on complex result operations (LRANGE_600: ~7,500 rps → ~17,000 rps). Even for the simpler StringGet/Set operations used here, the new IO core should help under load.

Pre-existing Concern (not introduced by this PR)

The version appears in two places:

1. Directory.Packages.props (Central Package Management — PackageVersion element)
2. examples/CloudShop/CloudShop.Tests/CloudShop.Tests.csproj (explicit PackageReference with Version attribute)

With CPM enabled (ManagePackageVersionsCentrally=true), individual .csproj files typically should not specify a version — CPM manages that centrally. The other packages in that same .csproj (Npgsql, RabbitMQ.Client, Microsoft.Testing.Platform.MSBuild) are NOT in Directory.Packages.props, suggesting the examples/CloudShop tree may not inherit from the root CPM file at all.

If that's the case, the Directory.Packages.props entry may be unused by CloudShop and could be stale — or it's for another consumer not immediately apparent. Worth investigating separately, but this is a pre-existing condition that this PR correctly keeps in sync.

Verdict

Approved. The upgrade is safe given the no-API-change guarantee, and the performance improvement is a net positive. The CPM duplication is worth investigating in a follow-up but doesn't block this update.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity

Metric	Results
Complexity	0

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}