fix(sdk): route Go SDK envd RPCs to the envd port (49983)#821
Merged
Conversation
Collaborator
newEnvdRequest — the shared request builder for every envd data-plane RPC (commands, files, filesystem, and the PTY added in TencentCloud#815) — hardcoded the Jupyter port (49999) as the virtual host prefix. CubeProxy routes by that prefix, so these requests reached the Jupyter kernel gateway, which does not serve /process.Process/*, /files, or /filesystem.Filesystem/*, yielding a non-2xx error (HTTP 404 or 502, depending on the template's Jupyter upstream) against real deployments. Only RunCode (/execute) worked, since /execute genuinely lives on the Jupyter port. Add a dedicated EnvdPort (49983) constant and use it in newEnvdRequest, matching the Python (ENVD_PORT) and Node SDKs; RunCode's /execute stays on JupyterPort. Update the affected unit-test host assertions and the README proxy example. Verified against a live CubeSandbox: /files read/write and filesystem.Filesystem/* now succeed on 49983 (previously non-2xx on 49999). Closes TencentCloud#816 Signed-off-by: chaojixinren <chaoji_xinren@163.com>
chaojixinren
force-pushed
the
fix/go-sdk-envd-port
branch
from
23d4160 to
762660b
Compare
chenhengqi
approved these changes
Jul 9, 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
4 participants
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
Fixes #816. Every envd data-plane RPC in the Go SDK was routed to the sandbox's Jupyter port (
49999) instead of the envd port (49983), soCommands.Run,Files.*,Filesystem.*, and thePtyfrom #815 all failed against real deployments (non-2xx —404or502depending on the template's Jupyter upstream). OnlyRunCode(/execute) worked, since/executegenuinely lives on the Jupyter port.Root cause
newEnvdRequest— the shared request builder for all envd RPCs — hardcodeds.GetHost(JupyterPort). CubeProxy routes by the<port>-<sandboxID>.<domain>host prefix, so these requests reached the Jupyter kernel gateway, which does not serve/process.Process/*,/files, or/filesystem.Filesystem/*.Changes
EnvdPort = 49983constant (sandbox.go).s.GetHost(EnvdPort)innewEnvdRequest(envd.go);RunCode's/executestays onJupyterPort.sdk_test.go) and the README proxy example.This matches the Python (
ENVD_PORT) and Node SDKs, which keep the two ports separate. It's effectively a one-line routing fix — everynewEnvdRequest-based API (including the PTY in #815) recovers automatically.Testing
gofmt/go vet ./...clean;go test -race ./...green.api=127.0.0.1:13000,proxy=127.0.0.1:11080,domain=cube.app):/filesread/write and/filesystem.Filesystem/*(mkdir/list/stat) now succeed on49983. Same-sandbox A/B confirms the routing: identicalGET /filesreturns non-2xx on49999but200on49983— the port prefix is the only difference.Scope
Routing fix only. A separate, independent framing bug on the streaming
/process.Process/Startrequest (its body isn't Connect-enveloped instartProcess, unlike Python and the Go PTY) is tracked separately and will be its own PR; it does not affect/filesor/filesystem.Filesystem/*.