Repository navigation
Conversation
…oxy ErrorHandler
The proxy ErrorHandler returned the same "Failed to route request to
sandbox" message for two unrelated cases: a genuine routing failure
(destination not resolved, 500) and an upstream/transport failure after
the destination was already resolved (502). Operators reading the logs
could not tell a real routing problem apart from a client that dropped a
large upload or an envd that answered 5xx.
- The 502 path now returns a distinct message ("Failed to reach sandbox
(upstream connection error)"), so the 500 routing failures and the 502
upstream failures are unambiguous in both logs and client responses.
- Client-caused disconnects (context.Canceled, ECONNRESET, io.EOF) are
logged at Warn instead of Error. A weak/CGNAT link dropping a large
POST /files upload, or an SDK giving up mid-request, is not a server
fault and should not drown real upstream errors in ERROR-level noise.
AdaAibaby
requested review from
ValentaTomas,
dobrac and
jakubno
as code owners
October 19, 2026 06:35
This branch has not been deployed
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
2 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.
What & why
The reverse-proxy
ErrorHandlerinpackages/shared/pkg/proxy/pool/client.goreturned the same"Failed to route request to sandbox"message for two unrelated cases:getDestination!ok, or emptyHost) →500.502(final fallback).Operators could not tell a real routing problem apart from ordinary client-caused noise (a weak/CGNAT link dropping a large
POST /filesupload, or an envd answering 5xx). See #3691 for production detail.Changes
"Failed to reach sandbox (upstream connection error)"with502, leaving the500routing-failure messages untouched. The two classes are now unambiguous in both logs and client responses.context.Canceled,syscall.ECONNRESETandio.EOFare client/network aborts, not server faults, so they log at Warn instead of Error and stop drowning real upstream errors in ERROR-level noise. (Extends the existingcontext.Canceledspecial-case to also cover reset/EOF, and applies it regardless of port.)No behavioral change to routing, status codes for the routing-failure paths, or the closed-port path.
Testing
gofmtclean.go build ./pkg/proxy/pool/passes.Closes #3691