fix: allow ioredis to resolve IPv6-only Redis endpoints (#15290) - #15309

@codex review

Codex Review: Didn't find any major issues. 🚀

Reviewed commit: d394341a67

Hi @danny-avila — just following up on this PR (fix for #15290, IPv6-only Redis endpoints). The Codex review came back clean ("didn't find any major issues"), and the branch is up to date with main. Anything else you'd like changed before merge, or is it good to go? Happy to adjust if needed. Thanks!

Heads up @danny-avila — the Cache Integration Tests failure (Redis Cluster step) was a bug in my own new test, not in the fix. 😅

Root cause: under the cluster CI step (USE_REDIS_CLUSTER=true), every module load creates an IoRedis.Cluster client, whose options nest family under redisOptions. My "single instance" address-family test asserted a top-level family on .options — which only holds for the standalone new IoRedis(...) branch — so it only passed in the single-node step by accident.

Fix (5e733fc1): the test now explicitly sets USE_REDIS_CLUSTER=false + the standalone REDIS_URI before importing the module, so it deterministically exercises the non-cluster branch in both CI steps (the cluster assertion already sets its own env). The actual family: 0 code change is untouched.

CI is re-running now — should go green on both the single-node and cluster steps.

Small follow-up: the workflow runs on the new head (5e733fc1) are queued with action_required — they need a maintainer to approve them before they start (Cache Integration Tests among them). If you could approve when you get a chance, I'll confirm green across both the single-node and cluster steps.

Rebased onto current dev (c2d02a0ca124). Two things worth flagging, one of which changes how you should read this PR.

The nine red checks on the previous head were not test results. On 5e733fc1 (Sep 2) nine workflows all failed within the same minute — Static Checks, Backend Unit Tests, Cache Integration Tests, Playwright E2E, Docker Build Smoke, Agents Integration, Codegraph Select, Bombadil, Retarget PRs — and every one of them recorded zero jobs. A run that fails with no jobs never reached a single step, so none of those nine ran a test or a linter. They do not represent failures in this change. This head supersedes them; the checks will re-run from a current base.

redisClients.ts was refactored on dev since this branch was opened. It now has startRedisHeartbeat / isReadonlyReplicaError / createReadonlyRecovery / keyv script routing, and my original two-line insertion was written against the older file. A naive replay would have reverted that work, so this is a three-way merge: the insertion is reapplied inside the current redisOptions object and the refactor is untouched. The diff against dev is +36/-0 across all four files — nothing removed, which is the property to check if you want to confirm nothing was clobbered:

• redisClients.ts +9
• experimental.js +2
• flush-cache.js +2
• redisClients.cache_integration.spec.ts +23

I also checked whether dev had already solved this, and it has not. The dnsLookup now present in redisClients.ts is the REDIS_USE_ALTERNATIVE_DNS_LOOKUP passthrough (it returns the address unchanged); it is opt-in and does nothing for address-family selection. There is no family setting anywhere on dev, so the underlying bug from #15290 is still open.

What the fix is. ioredis defaults to family: 4. On an IPv6 single-stack cluster the Redis hostname has no A record, so the connection fails with ENOTFOUND before authentication is attempted. family: 0 accepts either family and lets Node resolve both records and connect via Happy Eyeballs (autoSelectFamily, default since Node 20), so dual-stack hosts may now use IPv6 as well. Applied to the single-instance options, the cluster redisOptions, and the two standalone scripts (flush-cache.js, experimental.js) so the same URI behaves consistently everywhere.

The integration spec asserts the option lands where each client type reads it — options.family for a single instance, options.redisOptions.family for a cluster — which is the part that broke on the earlier head.

One thing I cannot do from here: the workflows on this head will sit at action_required until a maintainer approves them, so the fresh runs need your click before they will report anything.