element-hq / element-hq/synapse
Worker-mode redis/replication connection fails on IPv6-only (AAAA-only) hosts — txredisapi resolver is IPv4-only
- Dominant language
- Python
- Stars
- 4.6k
- Forks
- 600
- Avg merge
- 5d 22h
- Merged PRs (30d)
- 51
Description
### Description
Synapse's redis-based replication/pub-sub (`redis:` config, worker-mode deployments) can't connect to a redis/valkey host on an IPv6-only network — i.e. a host whose DNS name resolves *only* via AAAA, with no A record at all. The connection fails with a DNS lookup error before a socket is ever opened, even though the host is reachable over IPv6 and `socket.getaddrinfo()` resolves it correctly from the same environment.
Root cause is in `txredisapi`, not Synapse: it connects via Twisted's legacy `reactor.connectTCP()`, which — absent an explicitly installed custom resolver — resolves hostnames through Twisted's default `BlockingResolver`, whose implementation is a direct `socket.gethostbyname()` call. That function only ever queries A (IPv4) records; it has no AAAA/IPv6 awareness regardless of platform. Full trace (both the txredisapi and Twisted source) and a suggested fix (migrate to Twisted's `HostnameEndpoint`, which resolves via `getaddrinfo`) is filed upstream: https://github.com/IlyaSkriblovsky/txredisapi/issues/161
Scope: this only affects worker-mode deployments that actually enable `redis:` for replication — a single-process/monolith Synapse never touches this code path at all, since redis is entirely optional there.
### Steps to reproduce
1. Run Synapse in worker mode on an IPv6-only network (no IPv4 anywhere), with `redis.host` pointing at a redis/valkey/compatible server whose DNS name has only an AAAA record.
2. Start Synapse.
3. Observe the replication/redis connection fail with a DNS resolution error, despite `python -c "import socket; print(socket.getaddrinfo('', ))"` resolving the same name correctly from the same environment.
### Homeserver
N/A (general deployment issue, not homeserver-specific)
### Synapse Version
current (matrix-synapse chart / element-hq/synapse, txredisapi as currently pinned)
### Installation Method
Other (Kubernetes / Helm)
### Platform
IPv6-only network — no IPv4 addresses assigned anywhere in the deployment environment.
### Relevant log output
_No response — this is a connection-establishment failure at the DNS layer; see the linked txredisapi issue for the exact traceback shape (`DNSLookupError` via Twisted's `BlockingResolver.getHostByName`)._
### Anything else that would be useful to know?
Given IPv6-only deployments are only going to become more common, and this is a real gap for anyone running worker-mode Synapse in one: worth deciding whether the fix should land as a txredisapi patch (matching the precedent set by #19238 → txredisapi's username-auth patch) or whether it's worth reconsidering the dependency itself — happy to help with either.
Contributor guide
Research direction
Start with Synapse's worker-mode redis configuration and the txredisapi issue #161, then trace how the replication/pub-sub connection is established through Twisted. Decide whether the fix belongs in txredisapi or Synapse, and verify that an AAAA-only redis host connects successfully without breaking existing worker-mode deployments.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes, python, redis
- Domain
- backend, distributed-systems, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100