test(redis): lock in cluster-safe single-key invariant

[mrjasonroy]

Why

The data-cache handler is compatible with Redis Cluster / ElastiCache (cluster-mode enabled) purely because it only ever issues single-key commands — Redis rejects any command spanning more than one hash slot with CROSSSLOT. That's an invariant worth guarding.

What

• Test (redis.test.ts → "only ever issues single-key commands"): records every command the handler issues across its full surface — including both the tag-driven and TTL-driven deletion paths — and asserts none targets >1 key. Non-vacuous: it also asserts the del paths actually executed, so it fails loudly the day someone adds a del(k1, k2) / mget / multi-key transaction.
• Docs (docs/redis.md): document the slot-safety guarantee, and clarify cluster-mode-disabled (single-node-equivalent) vs cluster-mode-enabled (ioredis Cluster client) ElastiCache.

Why not a live cluster CI job

Considered it, decided against:

• A live cluster mostly exercises ioredis's redirect handling, not this library.
• Redis Cluster in CI is a well-known flake source — as a required check it could wedge the hands-off auto-merge release gate we just built.
• The thing that actually matters — the single-key invariant — is guarded here for free, with zero infra.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request adds documentation and a test suite to ensure and explain Redis Cluster safety, verifying that the handler only issues single-key commands to prevent CROSSSLOT errors. The feedback suggests making the new test more robust by asserting the exact keys that are deleted rather than just checking if any deletion occurred.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

While asserting that del was called is a good sanity check, we can make this test significantly more robust and precise by asserting the exact keys that were deleted (nextjs:data-cache:k1 and nextjs:data-cache:k2). This ensures that the correct keys are targeted for deletion and prevents false positives where del might be called with unexpected keys.

    // Both deletion paths must have run (otherwise the assertion is vacuous)...
    const delCommands = commands.filter((c) => c.method === "del");
    expect(delCommands).toEqual([
      { method: "del", keys: ["nextjs:data-cache:k1"] },
      { method: "del", keys: ["nextjs:data-cache:k2"] }
    ]);