bug/executors: dind frontend port mismatch#453
Open
DaedalusG wants to merge 1 commit into
Open
Conversation
ntend configmap
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.
closes PLAT-757
Description
The executor Kubernetes deployment configurations contain incorrect or incomplete
frontendUrlvalues that cause the executor to silently hang on startup, never connecting to the Sourcegraph instance.The Sourcegraph frontend Kubernetes service exposes port 30080 in both Helm and Kustomize deployments. The Kustomize executor ConfigMap patches ship with
http://sourcegraph-frontend(no port), and the Helm dind chart'svalues.yamlprovides no guidance on the correct port. Both result in a silent connection failure with no error log.When a URL omits the port, the HTTP client defaults to port 80 per the HTTP spec. The frontend Kubernetes service does not listen on port 80, so the connection attempt hangs indefinitely — no TCP RST (because the pod IP exists), no application-level error (because the request never reaches the frontend), and no timeout (because Go's default HTTP client has no dial timeout configured). The executor simply blocks forever on its initial connection attempt with no indication of what went wrong.
How I Identified It
During end-to-end testing of the executor dind Helm chart in a local kind cluster (Apple Silicon / OrbStack with Rosetta), the executor container started successfully but never registered with the Sourcegraph instance. The executor logs showed:
{"Body":"Connecting to Sourcegraph instance","Attributes":{"url":"http://sourcegraph-frontend:3080"}}No follow-up log ever appeared — no "Connected", no error, no timeout. The container sat indefinitely on this line. I confirmed the frontend pod was healthy (1/1 Running, HTTP 200 via port-forward).
Testing connectivity from within the executor pod (via the dind sidecar) revealed the issue:
The frontend service definitions confirmed it:
After changing
frontendUrltohttp://sourcegraph-frontend:30080, the executor connected immediately.Note: The incorrect port (3080) in my test came from my own override file, not from a docs example — the docs don't show any port at all, which is part of the problem.
Checklist
Test plan