Files
tech-log-backend/docs/redis/upgrade-guide.md
T

2.9 KiB

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.