test(elasticache): real TLS + auth coverage, not a plaintext stand-in

[mrjasonroy]

Why

The README/CI claim ElastiCache is covered by the e2e suite, but the coverage was hollow:

• The e2e-elasticache job ran the handler against a plaintext Redis container — ELASTICACHE_TLS: "false" and no auth token. That exercises the switch branch but with the exact two things that differ on a real ElastiCache cluster (in-transit TLS + auth token) turned off. It was wire-identical to the plain redis job.
• factory.test.ts had no elasticache case at all.

So the part most likely to break against real ElastiCache — the TLS handshake and AUTH — was never tested. (Found while wiring this handler to a live AWS ElastiCache cluster with in-transit encryption + an auth token.)

What

1. Unit coverage for the factory's elasticache branch (factory.test.ts, no network)
Asserts ELASTICACHE_* env vars and explicit options map to the ioredis config — host/port, TLS-on-by-default, auth-token password, connectTimeout, retryStrategy — and that a missing endpoint throws. Reuses the existing ioredis mock.

2. e2e-elasticache CI job now runs against TLS + AUTH (.github/workflows/ci.yml)

• Generates a self-signed CA + server cert (SAN=localhost).
• Starts Redis with --tls-port 6379 --tls-auth-clients no --requirepass <token> (server-side TLS + auth token, no client certs — mirroring real ElastiCache).
• Trusts the CA via NODE_EXTRA_CA_CERTS, so the factory's tls: {} (default certificate verification) succeeds against localhost.
• Flips the job env to ELASTICACHE_TLS: "true" + ELASTICACHE_AUTH_TOKEN.

No AWS needed — a TLS+auth Redis is wire-identical to ElastiCache for this code path (there's zero AWS-SDK code in it; the only difference is which CA signs the cert). The real TLS handshake + AUTH are now exercised end to end.

3. e2e app builds through the package factory (apps/e2e-test-app/data-cache-handler.mjs)
The elasticache branch hand-wired ioredis (a copy of the factory logic). It now calls createCacheHandler({ type: "elasticache" }), so the e2e covers the shipped code path rather than a duplicate.

Verification (local)

• vitest run factory.test.ts → 9/9 pass (4 existing + 5 new)
• tsc --noEmit clean · biome check clean
• The TLS round-trip runs in CI on this PR.

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request refactors the e2e test application to use the package's createCacheHandler factory for the elasticache cache type, replacing custom ioredis initialization. It also adds comprehensive unit tests for the elasticache factory branch, covering environment variable mapping, option overrides, and error handling. Feedback on the tests suggests verifying the behavior of the retryStrategy function and adding a test case to ensure that passing tls: false in the options successfully overrides the default TLS behavior.

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.