DongHyeonkaandClaude Opus 5
5f10b791d3
Snapshot of the in-flight state that already existed, identically, in both this worktree and the main checkout before this session began: the initial HTTP Client platform implementation (previously untracked), the redis-lab removal, and the JPA / object-storage / notification integration work. Kept separate from this session's HTTP Client review response, which lands in the following commit, so the two bodies of work stay reviewable apart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.