Background
The connectivity check added in #144 classifies network errors (TIMEOUT, REFUSED, RESET) from real socket/HTTP exceptions. The classifier logic is unit-tested in ConnectivityErrorClassifierTest, but the full controller path — socket open, TLS handshake, HttpClient send, git probe — can't be exercised without a real network. Toxiproxy fills that gap.
Toxiproxy is a TCP proxy that can inject latency, bandwidth limits, connection resets, and timeouts programmatically via a REST API. A Java client (eu.rekawek.toxiproxy:toxiproxy-java) is available. It runs as a Docker image (ghcr.io/shopify/toxiproxy).
Two test areas
point 1 — Connectivity check validation
Testcontainers test that starts Toxiproxy and routes a provider through it:
| Toxic injected |
Expected result |
| None |
TCP ok, TLS ok, HTTP ok |
reset_peer on connect |
TCP RESET |
timeout (no data) |
TCP TIMEOUT |
reset_peer after TLS |
TLS or HTTP error (depends on timing) |
reset_peer only on git probe port |
HTTP ok, git probe RESET — git-specific filtering confirmed |
The last case is the one hardest to simulate any other way: it proves the git probe catches something the HTTP check misses.
point 2 — Proxy server reliability
Toxiproxy between the proxy and a Gitea upstream (reusing the existing Testcontainers Gitea fixture) to validate how the proxy behaves under degraded network conditions:
- Intermittent resets mid-push → does the proxy surface a clean error or hang?
- High latency → does the proxy time out gracefully?
- Bandwidth limit → does store-and-forward complete correctly vs transparent proxy?
Implementation notes
- Tag all tests
@Tag("e2e") — they need Docker/Podman and are excluded from ./gradlew test
- Add Toxiproxy container as a
@Container alongside existing Gitea fixture in the e2e test module
- Use the Toxiproxy REST API (or Java client) to inject and remove toxics between test cases — don't share toxic state across tests
- For connectivity check tests: configure a test provider that points at the Toxiproxy port, not directly at the upstream
- Java client option:
eu.rekawek.toxiproxy:toxiproxy-java — verify it works against the current Toxiproxy image version before committing to it
Related
Background
The connectivity check added in #144 classifies network errors (TIMEOUT, REFUSED, RESET) from real socket/HTTP exceptions. The classifier logic is unit-tested in
ConnectivityErrorClassifierTest, but the full controller path — socket open, TLS handshake, HttpClient send, git probe — can't be exercised without a real network. Toxiproxy fills that gap.Toxiproxy is a TCP proxy that can inject latency, bandwidth limits, connection resets, and timeouts programmatically via a REST API. A Java client (eu.rekawek.toxiproxy:toxiproxy-java) is available. It runs as a Docker image (
ghcr.io/shopify/toxiproxy).Two test areas
point 1 — Connectivity check validation
Testcontainers test that starts Toxiproxy and routes a provider through it:
reset_peeron connecttimeout(no data)reset_peerafter TLSreset_peeronly on git probe portThe last case is the one hardest to simulate any other way: it proves the git probe catches something the HTTP check misses.
point 2 — Proxy server reliability
Toxiproxy between the proxy and a Gitea upstream (reusing the existing Testcontainers Gitea fixture) to validate how the proxy behaves under degraded network conditions:
Implementation notes
@Tag("e2e")— they need Docker/Podman and are excluded from./gradlew test@Containeralongside existing Gitea fixture in the e2e test moduleeu.rekawek.toxiproxy:toxiproxy-java— verify it works against the current Toxiproxy image version before committing to itRelated