RedisCache update in .NET 6 breaks usage against older redis servers

[mgravell]

Timeline:

• redis 2.0 had HSET key field value for setting individual hash fields, and HMSET key field value [field value ...] for setting multiple hash fields (against the same key); as you can see, there's a lot of overlap here
• redis 4.0 observes this redundancy, and adds HSET key field value [field value ...], and also marks HMSET as deprecated, although it still works fine
• RedisCache wants to set a hash with 3 fields against a single key; historically it has used HMSET for this (via Lua)
• .NET 6 switches to using the non-deprecated HSET API

Impact:

For users targeting redis versions that lack the varadic HSET (so: versions before 4.0), it simply doesn't work, manifesting in a RedisServerException:

Wrong number of args calling Redis command From Lua script

Suggestions:

1. check the redis server version (APIs exist on SE-Redis for this) before deciding which to use
2. or, just use HMSET; it hasn't gone anywhere, and is honestly: unlikely to go anywhere
3. make 3 simple calls to HSET, which would work everywhere and still be contiguous (thanks to the single-threaded core) - although I confess that this is inelegant

A complicating factor is that the Redis-64 port of Redis on Windows by Microsoft (now abandoned): stops at 3.0.503. Alternatives for Windows hosting are WSL or Memurai (commercial), or containers such as Docker. This means that some folks have (perhaps unwisely) stagnated on v3, wanting to keep things simple.

Links:

• relevant .NET 6 change: here
• existing aspnetcore bug, ccing @JunTaoLuo who closed it (I can't comment on the existing one)
• customer impact (being reported in the SE-Redis library)

[adityamandaleeka]

We've had other reports of this issue (e.g. #38254 and #38606). Since the older Redis versions are deprecated, we've been asking that people update their Redis to fix this issue.

As you mentioned, people who were using Redis-64 have options like moving to WSL or docker, so we don't believe this is blocking customers.

We're open to suggestions if there's something we can do to make this experience better though... the error message is clearly not the most helpful for instance.

[mgravell]

Honestly, if it was up to me I'd say "just use HMSET" - which works fine everywhere, and causes zero problems. It isn't obvious to me what the .NET 6 change adds, other than cutting off some customers (who demonstrably exist). If there are other features you're using, it might be different, though.

If that outcome isn't on the table, then I'd suggest at least trying to catch this specific error and give a good error message telling them the minimum supported redis version. I'm probably a little biased here, because right now: we're getting some of the noise from this over in the SE-Redis side (although at least now that we understand the problem, that is easier to deflect).

Depending on how much trouble you're willing to go to: I can also offer guidance (or even just a PR) that adds server version testing into the mix. Or maybe simpler: just a blind fallback, i.e.

• have a flag that is "am using fallback HMSET"
• pick the command based on the current value
• if it fails in the way observered and we sent the up-level version, just toggle the flag (for future callers) and retry with the down-level (only retry if it was up-level when we sent it)

[adityamandaleeka]

Thanks @mgravell, we're open to making this experience better for people stuck on older versions. Your proposed idea of just checking Redis version and then calling the right API makes sense.

We'll also need to consider backporting this to 6.

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[NickCraver]

@adityamandaleeka +1 for backporting here - we are getting more reports from people breaking in their .NET 6 upgrade on the library side. We can detect one of many servers and see if their version is >= 4.0 for the varadic overload (which assumes sibling server level, but is probably generally okay)...or we could revert the change and use the deprecated but working-everywhere command. I think people upgrading-to-fix is much better than upgrading-to-break and using the version that works across the board is the former here.

In general, I don't think "we only support the supported versions of Redis" is a good approach for any client library to take - in practice we need to go back further. Keep in mind that until only weeks ago, even Azure only had a 4.x level available as a service, so the argument in the issue of 5.2 being the minimum is something I want to call out on the approach side...we need to be a bit wider than that.