mirror of
https://github.com/element-hq/synapse.git
synced 2026-11-04 22:07:34 +00:00
Erik JohnstonandClaude Opus 5.5
6a2ac9be0e
The Rust replacement for `MatrixFederationAgent` and its connection pool, as a library: nothing in Synapse sends through it yet. The request layer (signing, retries, backoff) comes next and will be its first caller. `Agent::request` takes a `matrix-federation://` request, applies `.well-known` delegation to the URI and the `Host` header, and sends it through hyper-util's pooled client (5 idle connections per host, 120s idle timeout, HTTP/1.1, no automatic retries), as Python's pool does. The pool calls our connector, derived from matrix-hyper-federation- client's `MatrixConnector` (Apache-2.0). It resolves the server name (SRV), tries each server in order and returns the first error if all fail. For each server it resolves addresses through the IP range policy, connects TCP with Twisted's staggered attempts and 30s timeout, or tunnels through `https_proxy` with `CONNECT` unless `no_proxy` exempts the host, then does TLS verified against the delegated server name, never the SRV target. The `.well-known` fetch shares the pool and, as in Python, blocks IP literals by the blocklist alone. Failures are a typed `TransportError` (DNS, connect, TLS, and so on), so the request layer can tell a DNS failure from the rest. The agent implements `FederationTransport`. `RustFederationAgentForTest` exposes a blocking `request` to Python. The trial tests drive it against a real TLS server on a thread, signed by the test CA, covering the delegation, SRV, SNI, IP literal, blocklist, certificate verification and connection reuse cases. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01R5b7Ruy4cgt27Mjq6Ptxbb