Extract a swappable networkProxy seam from deployOps - #5906
Merged
Conversation
Introduces a networkProxy interface as the single enforcement point for proxy container setup (egress forward proxy, ingress reverse proxy). The existing Squid logic moves behind a squidProxy backend selected via TOOLHIVE_NETWORK_PROXY (default: squid). Fails loudly on unknown values. SetupProxies is now invoked before createMcpContainer so the returned env vars can be injected into the workload; port extraction for non-stdio transports is done before the call (stdio short-circuit preserved). Also fixes two pre-existing copy-before-mutate violations in addEgressEnvVars and generatePortBindings. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
ChrisJBurns
requested review from
JAORMX,
amirejaz,
blkt,
jhrozek and
rdimitrov
as code owners
July 21, 2026 23:23
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5906 +/- ##
==========================================
- Coverage 71.63% 71.58% -0.05%
==========================================
Files 698 699 +1
Lines 71541 71575 +34
==========================================
- Hits 51245 51239 -6
- Misses 16598 16655 +57
+ Partials 3698 3681 -17 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
10 tasks
JAORMX
previously approved these changes
Jul 22, 2026
The single SetupProxies call ran before createMcpContainer, which created the Squid ingress reverse proxy before the MCP container existed. Squid resolved the cache_peer upstream hostname on first probe, cached the negative DNS result, and never recovered within the readiness window, so isolated non-stdio workloads hung in "starting" and E2E timed out. Restore the original, proven ordering by splitting the seam into SetupEgress (before the MCP container, so proxy env vars are injected and egress gets a head start) and SetupIngress (after it, so the reverse-proxy upstream resolves immediately). A consolidated backend threads any reserved state forward through egressResult, avoiding per-workload state on the shared proxy. Verified locally: an isolated Squid workload now reaches running with a healthy ingress. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
JAORMX
approved these changes
Jul 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
deployOpsinterface inpkg/container/dockermixes proxy-container concerns (egress/ingress) with workload-container concerns (DNS, MCP container creation), which makes it impossible to swap the proxy backend without splitting the interface. This PR extracts anetworkProxyseam so the backend becomes pluggable, and re-homes the existing Squid logic behind it. Pure refactor — no user-visible behavior change, Squid stays the only backend.Closes #5901. Part of #5900.
Medium level
networkProxyinterface with a singleSetupProxies(ctx, proxySpec) (proxyResult, error)method, plusproxySpec/proxyResultvalue types.deployOpsinto asquidProxyimplementation;deployOpsno longer owns proxy methods.newNetworkProxyfactory readsTOOLHIVE_NETWORK_PROXY(""/squid→ Squid) and fails loudly atNewClienton unknown values.SetupProxiesis invoked beforecreateMcpContainerso returned proxy env vars can be injected into the workload; port extraction for non-stdio is done before the call, preserving the stdio short-circuit.addEgressEnvVarsandgeneratePortBindingssurfaced by the refactor.Low level
pkg/container/docker/networkproxy.gonetworkProxyinterface,proxySpec/proxyResult,newNetworkProxyfactory, compile-time assertionpkg/container/docker/squid.gosquidProxytype wrapping the existing egress/ingress funcspkg/container/docker/client.godeployOps; addproxyfield +newNetworkProxywiring inNewClient; callSetupProxiesbeforecreateMcpContainer; copy-before-mutate fixespkg/container/docker/networkproxy_test.gopkg/container/docker/client_deploy_test.gofakeDeployOps→fakeNetworkProxy; add call-ordering testType of change
Test plan
task buildpassestask testpasses forpkg/container/docker/...with-racegolangci-lintclean on the changed packageTestNewNetworkProxy— default/squidselect Squid; unknown value errorsTestDeployWorkload_Isolated_SetupProxiesBeforeCreateMcp— assertsSetupProxiesruns beforecreateMcpContainerTestDeployWorkload_*), including non-bridge-mode dropSpecial notes for reviewers
Pure refactor foundation for the Envoy backend (#5902). The one behavioral nuance: proxy setup now happens before MCP container creation so proxy env vars can be injected — guarded by an explicit ordering test. Squid remains the default and its config generation is untouched.
Generated with Claude Code