# Redis and client upgrade gate Changing the Redis server version or the Lettuce version is not a dependency bump. Both change what commands exist, what they reply, and what an ACL account is allowed to do — all three are things this SDK encodes as fixed decisions. The checks below must pass before either version moves, and each one exists because skipping it produces a specific failure that only shows up in production. ## 1. Command metadata diff Run the catalog drift check against the new server. Every command the server reports must be classified in `src/adapter/outbound/cache-redis/src/main/resources/redis-sdk/redis-command-policy.yml`. *Why:* an unclassified command is refused by `CommandPolicyGuard`, so a server that grew a command does not create a hole — but a command whose **risk changed upstream** and is still classified R1 here does. The diff is what surfaces that. ## 2. ACL regression Re-run `ACL DRYRUN` for every account against every command the SDK can issue, using `RedisAdminOperations.aclDryRun`. *Why:* a permit never widens an ACL account, so the account is the last boundary. A new server version that moved a command into a different ACL category silently turns a working call into a runtime refusal on the first request that needs it. ## 3. Serializer golden bytes Compare the encoded form of every registered codec against the stored golden bytes. *Why:* a value written by the old version must still decode after the upgrade. A codec change that looks harmless in a round-trip test is not harmless against data already in the instance. ## 4. Support matrix Update `docs/redis/support-matrix.md`. `RedisSupportMatrixTest` fails when a module or capability is missing, and the certified-version table must not claim a version until its topology lane has actually run. ## 5. Topology suite Run the standalone, Sentinel, and Cluster lanes declared in `infra/redis-sdk/`. A version is certified by the lane passing, not by the version number being newer. *Why:* failover certainty and cross-slot behaviour are the two things the in-memory fixture cannot prove. `ExecutionCertainty` and `RedisSlotCalculator` are classification and arithmetic; whether the driver actually behaves that way during a promotion or a resharding is only observable on a real topology. ## 6. Rollback Before the upgrade, record the previous server version, the previous Lettuce version, and the `SCRIPT LOAD` digests of every registered script. A rollback is not complete until the digests resolve again on the restored version. *Why:* digests are cached per process and invalidated by `SCRIPT FLUSH` and by restarts. A rollback that leaves a process holding digests the restored server does not know produces `NOSCRIPT` on every scripted call until the cache is dropped. ## What this gate does not cover Data migration. Nothing here moves or reshapes stored values; a change that alters what is stored, rather than how it is addressed, needs its own plan.