Please remove Lua depreciated functions and ensure compatibility with Microsoft Garnet

[JohnGalt1717]

LUA has large sections depreciated in Redis and all of the clones don't support it as a result. Using it is both slower (according to the .net team) than alternatives, and unsupported.

It would be better to use something else because right now this library's use of LUA means that it isn't compatible with Garnet and others which is magnified by the lack of in memory providers for testing because Garnet provides an in memory server that gets around the lack of in memory providers.

#223 creates a feedback loop here and makes it incredibly difficult to create a good test suite that is performant and doesn't require docker containers that aren't issolated per test.

[madelson]

Hi @JohnGalt1717 thanks for your interest in the library.

LUA has large sections depreciated in Redis

Can you point me to which Lua features used by DistributedLock are deprecated in Redis/Valkey? I wasn't aware we were using any deprecated features.

Using it is both slower (according to the .net team) than alternatives, and unsupported.

Is this a bottleneck for your app? What alternatives are you comparing against?

In my view a benefit of the scripting approach is that there is just one round trip between the application and Redis and everything is 100% atomic which makes it easier to demonstrate the desired thread-safe behavior.

this library's use of LUA means that it isn't compatible with Garnet

Garnet isn't currently a supported back-end. If it were 100% Redis-compatible then it would be, but it sounds like that's not a goal of the project. That said, if someone were to contribute a compelling implementation I'd happily add it to the library. For example an option passed to the Redis classes that puts it in "Garnet compat mode" or similar.

#223 creates a feedback loop here and makes it incredibly difficult to create a good test suite that is performant and doesn't require docker containers that aren't issolated per test.

I'd love to have someone contribute on the in-memory implementation front. That said, there are several solid workarounds for unit testing:

• File-based locks are relatively dependency free and low-overhead
• On Windows, WaitHandle based locks are a very fast option
• The library exposes interfaces; anyone can use those to build lightweight testing implementations on top of .NET's in-process primitives. An implementation for a specific testing use-case can be simpler than a general-purpose implementation that has to conform to all of the library's guarantees.

[JohnGalt1717]

The page that used to exist on this topic: https://redis.io/docs/latest/develop/interact/programmability/lua-api/index.html.md

404s now.

Basically it was talking about all of the limitations to the api and apis that were removed or depreciated because of the security abuses that can be made with LUA.

As of right now, I don't believe that there are any of the wire compatible Redis clones like Garnet that support Lua for this reason. In the case of what DistributedCache in .NET was using in LUA they found that there were faster ways of doing it with other supported Redis functionality: dotnet/aspnetcore#54685

For right now I'm using the File based locks because testing has to work on Windows, Mac (both for developers) and Linux runners for CI/CD. I doubt I currently have time, but if I get some I'll contribute a Memory version.