Are you using Valkey or any other Redis fork?

[kamikazechaser]

This is just a temperature check discussion on what kind of Redis server implementation folks are using with this library.

There is some concern with these comments on the future of Redis client compatibility:

• Valkey redis/go-redis#3149 (comment)
• Future Crate Maintenance and Redis Inc. Relationship redis-rs/redis-rs#1419 (comment)

We could mitigate such issues if we can plan and work around this from now. (E.g. Starting with #976).

[hariangr]

I use Valkey both personally and at work
Initially I tried using Dragonfly, but it seems Dragonfly isn't supported by this library

[mortensi]

@kamikazechaser is there any specific concern you would like to address? Core data structures and access to core data structures, so the API to access functionalities are pretty stable, and there will not be any change that causes incompatibilities on the Redis side and with forks. For what concerns the clients, Redis clients are tested against all Redis flavors, including Community Edition. So, Redis clients are expected to continue working with forks unless changes Redis cannot control occur.

[kamikazechaser]

@mortensi No specific concern. I'm just seeing a lot of Redis libraries getting fractured/discussing the same issue. E.g. We have redis/rueidis and valkey-io/go-valkey which is pretty much the same library by the same author being maintained in 2 different places. This signals that compatibility (Either Valkey or Redis) might become an issue in the future. This is one of the most popular go libraries that uses Redis + Forks in a lot of different environments and we would like guarantee support for both because Valkey/Forks are rapidly gaining traction (e.g. Alibaba, AWS).

[mortensi]

Thanks, @kamikazechaser. I can tell and guarantee that Redis libraries are supported by both the community and the company, compatibility is granted, and alignment between different client libraries is pursued. If you experience any issues with the Redis libraries, let me know so we can check on a case-by-case basis.

[kamikazechaser]

@mortensi Appreciate it! I think the statements coming out of Redis these last few days are more reassuring!

[AlfredoRamos]

We were using Redis extensively and now, after running feature parity tests (specifically for our needs), we are in the process to migrate to Valkey and will be migrating more projects next year.

We already migrated some low-impact projects to valkey-io/go-valkey and we are actively monitoring. It's working great so far.

So we appreciate Valkey compatibility is being considered, since Asynq is one of the core libraries on our projects.

[atropos112]

I saw #769 talking about an error and how it makes dragonfly not compatible. I recall that dragonfly does have the functionality to allow undeclared keys, namely

--default_lua_flags=allow-undeclared-keys

I have tried the example code to create and consume the task and it worked as expected. Do you expect any hidden "side effects" or is this all there is to do to make dragonfly compatible.