test: validate Valkey as a Redis-protocol counter store

[daric93]

Description

The rate limit service reaches its counter store over the Redis protocol, through radix. Valkey serves that protocol, so it should work in that position unchanged — but nothing in the repo demonstrated it, and Redis and Valkey have developed independently since Redis 7.2, so command-level behavior can drift. This adds a Valkey run to the existing integration suite so the answer is a test rather than an assumption.

The integration target is parameterized over the store's server and CLI binaries, and the Redis and Valkey runs share one recipe:

Change	Detail
Makefile	tests_with_redis and the new tests_with_valkey both delegate to tests_with_store, selected by STORE_SERVER / STORE_CLI. The Redis recipe is unchanged apart from the substitution.
Makefile	make docker_tests_valkey runs that target in the integration image, as a separate container from make docker_tests.
Dockerfile.integration	Installs valkey-server and valkey-tools. Debian trixie main, already the base of this image, packages Valkey 8.1, so no third-party apt repository or binary download is needed, and the packages install alongside redis without conflicting.
CI	A build-valkey job runs make docker_tests_valkey on every pull request, next to the existing build job.
README.md	A Valkey section under Redis: Valkey can be used in place of Redis with no configuration change, plus the version and topologies that back the claim.

No change to src/. The same client, protocol, and settings serve both stores. Redis stays the default in docker-compose.yml, in the examples, and in the target CI already ran.

Related Issues/PRs (if applicable)

Related issue: #1247

This comes from the Envoy AI Gateway / Agent Router side. theagentrouter/agent-router#2522 asked whether validating Valkey against the documented token-rate-limit and quota paths was welcome there; in theagentrouter/agent-router#2719 the maintainer's answer was that the gateway is the wrong abstraction layer for testing Redis-protocol compatibility and that it belongs here. I agree, so that PR is being withdrawn in favor of this one.

The original Valkey work is by @atao2004, on the gateway side. This PR is a different change at a different layer, so it is not a port of that patch, but the idea is theirs.

Special notes for reviewers (if applicable)

• Why one shared recipe instead of two targets. The Redis recipe stands up eleven servers across single, sentinel, and cluster topologies; duplicating it for Valkey would guarantee the two drift. The cost is that tests_with_store uses fixed ports and directories, so one make invocation can serve only one store — make tests_with_redis tests_with_valkey would run the recipe once, not twice. There is a comment saying so, and docker_tests_valkey uses a separate container. If you would rather have the duplication and the independence, say so and I will split them.
• build-valkey is a separate job, not a matrix. A matrix over the store would have been tidier, but the two runs differ only in one make target, and a matrix would have renamed the existing build job and any branch protection attached to it. Happy to convert it if you would prefer.
• Whether this job should be required. It runs and reports as written. Tell me if it should block merges.
• Valkey version tracks Debian. The README says "Valkey 8.1 at the time of writing" rather than pinning a patch version, because the version follows whatever trixie ships. If you would rather pin it exactly, that is an apt pin in Dockerfile.integration.

Testing

Both runs were executed locally in the integration image, and both passed:

• make tests_with_valkey — the whole suite green, including test/integration at 94s, which is the sentinel, cluster, and stunnel TLS coverage. valkey-cli --cluster create formed both 3-primary clusters, all 16384 slots covered, and no redis-server process was started in that run.
• make tests_with_redis — green, and no valkey-server process was started, confirming the refactor left the Redis path alone.

make check_format and the doctoc and prettier pre-commit hooks are clean.

One local deviation worth naming: this machine cannot reach proxy.golang.org, so rather than make docker_tests_valkey end to end I built the same image without the go mod download layer and mounted a prepopulated module cache. The apt layer, the Makefile targets, and the suite itself are exactly what CI will run; only the module fetch differed.

AI usage disclosure

Claude was used to write these changes, run the two suites, and draft this description. I reviewed all of it, and the results above are from runs I have the logs for.

[ysawa0]

Thanks for adding Valkey coverage. The Valkey CI job is green, including the sentinel, cluster, and TLS paths.

One gap before I approve: tests_with_valkey switches the servers started by the Makefile, but test/common.WithMultiRedis still launches redis-server directly. That means TestBasicConfig, TestNegativeHitsIntegration, and TestBasicAuthConfig run against Redis in the Valkey job. Could you pass the selected server through to that helper and rerun CI? Then the README's claim that the full integration suite runs against Valkey would hold.

[daric93]

Fixed in 3f65129 — WithMultiRedis reads STORE_SERVER from the environment, defaulting to redis-server so a bare go test is unchanged, and the Makefile now exports it so the target-specific value from tests_with_valkey reaches go test.

Verified locally with valkey-server installed: of those ten tests, nine pass under STORE_SERVER=valkey-server. TestReloadGRPCServerCerts fails, but identically under STORE_SERVER=redis-server — it's a macOS tmpdir permission problem on my machine (/var/folders/.../TemporaryItems: operation not permitted), not store-related. I also confirmed the binary actually flows through by pointing STORE_SERVER at a nonexistent name and watching the helper try to exec it. CI is the real check for that last test.

The workflow runs need maintainer approval to start, so build-valkey hasn't run on this push yet.