starred/asynq

Fork 0

mirror of https://github.com/hibiken/asynq.git synced 2026-04-26 07:25:56 +03:00

[GH-ISSUE #981] Are you using Valkey or any other Redis fork? #1486

New issue

Closed

opened 2026-03-07 22:09:56 +03:00 by kerem · 9 comments

kerem commented

2026-03-07 22:09:56 +03:00

Owner

Originally created by @kamikazechaser on GitHub (Dec 9, 2024).
Original GitHub issue: https://github.com/hibiken/asynq/issues/981

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:

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

Originally created by @kamikazechaser on GitHub (Dec 9, 2024). Original GitHub issue: https://github.com/hibiken/asynq/issues/981 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: * https://github.com/redis/go-redis/discussions/3149#discussioncomment-10935875 * https://github.com/redis-rs/redis-rs/issues/1419#issuecomment-2502161761 We could mitigate such issues if we can plan and work around this from now. (E.g. Starting with #976).

kerem

2026-03-07 22:09:56 +03:00

closed this issue
added the
idea
label

kerem commented

2026-03-07 22:09:57 +03:00

Author

Owner

@hariangr commented on GitHub (Dec 11, 2024):

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

@hariangr commented on GitHub (Dec 11, 2024): I use Valkey both personally and at work Initially I tried using Dragonfly, but it seems Dragonfly isn't supported by this library

kerem commented

2026-03-07 22:09:57 +03:00

Author

Owner

@mortensi commented on GitHub (Dec 11, 2024):

@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.

@mortensi commented on GitHub (Dec 11, 2024): @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.

kerem commented

2026-03-07 22:09:57 +03:00

Author

Owner

@kamikazechaser commented on GitHub (Dec 11, 2024):

@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).

@kamikazechaser commented on GitHub (Dec 11, 2024): @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).

kerem commented

2026-03-07 22:09:57 +03:00

Author

Owner

@mortensi commented on GitHub (Dec 11, 2024):

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.

@mortensi commented on GitHub (Dec 11, 2024): 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.

kerem commented

2026-03-07 22:09:57 +03:00

Author

Owner

@kamikazechaser commented on GitHub (Dec 12, 2024):

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

@kamikazechaser commented on GitHub (Dec 12, 2024): @mortensi Appreciate it! I think the statements coming out of Redis these last few days are more reassuring!

kerem commented

2026-03-07 22:09:57 +03:00

Author

Owner

@AlfredoRamos commented on GitHub (Dec 26, 2024):

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.

@AlfredoRamos commented on GitHub (Dec 26, 2024): 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](https://github.com/valkey-io/valkey-go) 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.

kerem commented

2026-03-07 22:09:57 +03:00

Author

Owner

@atropos112 commented on GitHub (Dec 31, 2024):

I saw https://github.com/hibiken/asynq/issues/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.

@atropos112 commented on GitHub (Dec 31, 2024): I saw https://github.com/hibiken/asynq/issues/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.

kerem commented

2026-03-07 22:09:58 +03:00

Author

Owner

@ndreas commented on GitHub (Jan 21, 2025):

We're running Asynq and Dragonfly using --default_lua_flags=allow-undeclared-keys without any problems.

@ndreas commented on GitHub (Jan 21, 2025): We're running Asynq and Dragonfly using `--default_lua_flags=allow-undeclared-keys` without any problems.

kerem commented

2026-03-07 22:09:58 +03:00

Author

Owner

@kamikazechaser commented on GitHub (May 5, 2025):

Thanks for the feedback. With Redis reverting back to AGPL-3.0. This is a non issue.

@kamikazechaser commented on GitHub (May 5, 2025): Thanks for the feedback. With Redis reverting back to AGPL-3.0. This is a non issue.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/asynq#1486

No description provided.

Rows
Columns