net/rpc: no way to get visibility into write errors (debugLog isn't exposed or changed)

[lattwood]

Go version

go version go1.23.1 darwin/arm64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/loganattwood/Library/Caches/go-build'
GOENV='/Users/loganattwood/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/loganattwood/gopath/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/loganattwood/gopath'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.23.1/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.23.1/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.1'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/loganattwood/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/opt/homebrew/Cellar/go/1.23.1/libexec/src/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/cr/cbrcy4x955v17hhkg5vwr3gh0000gq/T/go-build2283193740=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

I was investigating this issue (I'm linking to a comment) hashicorp/yamux#143 (comment) that involved net/rpc.

The core of the issue is a Write error getting returned from the related codec was never going anywhere. The documentation for net/rpc.ServerCodec has WriteResponse returning an error: https://pkg.go.dev/net/rpc#ServerCodec

Requiring implementation of an interface to return an error implies that something is done with the error, and so I wanted to see the error that was getting returned. That's when I discovered that's controlled by net/rpc.debugLog. Unfortunately, that value is only ever read, and never written to.

The Gob Codec does do logging of errors-

go/src/net/rpc/server.go

Line 413 in b07b20f

log.Println("rpc: gob error encoding response:", err)

The jsonrpc Codec does not do logging of errors-

go/src/net/rpc/jsonrpc/server.go

Line 102 in b07b20f

func (c *serverCodec) WriteResponse(r *rpc.Response, x any) error {

What did you see happen?

Errors were silenced, and there's no way to enable debugLog w/o modifying and recompiling the net/rpc package.

insert something tongue-in-cheek about proving a negative

What did you expect to see?

I expected a couple things

• a way to enable net/rpc error logging that doesn't involve modifying the standard library and recompiling
• some indicate there was an error returned from WriteResponse when replying to a net/rpc call
• the various net/rpc codecs in the Go standard library be internally consistent wrt logging of errors
• the (disabled) log messages would actually indicate there's an error (gob codec includes the word error in its log messages, but net/rpc just prefixes them with rpc:)
• (wish list) when net/rpc calls WriteResponse on a codec and it returns an error, it should then call Close. Based on this comment in the documentation, this should not cause consistency issues- Close can be called multiple times and must be idempotent.

[gabyhelp]

Related Issues

• net/rpc: error not returned if ClientCodec.WriteRequest sleeps #38681
• net/rpc: gob encoding error not returned in response #7689 (closed)
• x/tools/gopls: omit empty JSON-RPC error data #39736 (closed)
• net/rpc: server.Register() should not internally log by default #19957 (closed)

Related Discussions

• proposed change to net/rpc gobServerCodec implementation

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

As the package docs indicate, the package is frozen. I don't think any chance will be made here, sorry.

[lattwood]

@seankhliao would it make sense to move The net/rpc package is frozen and is not accepting new features. to the header of the godoc for the page, and to be explicit about the fact that bugs will not be getting addressed any more?

if that extends even to security issues, can net/rpc be added to vulndb to encourage/force a migration away?

if need be i can open another issue.

[ianlancetaylor]

We will still address bugs, but the fact that debugLog is not exposed is not a bug.

I sent https://go.dev/cl/646575 to move up the notice. Thanks for the suggestion.

[gopherbot]

Change https://go.dev/cl/646575 mentions this issue: net/rpc: move frozen notice to the start of the package doc

[lattwood]

@ianlancetaylor would "errors returned when writing to the provided codec are silently dropped" be a bug?

edit: my comment about bugs not getting fixed stems from the original justification @robpike had for freezing it

The package has outstanding bugs that are hard to fix, and cannot support TLS without major work. So although it has a nice API and allows one to use native Go types without an IDL, it should probably be retired.

The proposal is to freeze the package, retire the many bugs filed against it, and add documentation indicating that it is frozen and that suggests alternatives such as GRPC.

heavily implies bugs will not be fixed going forward

#16844

[ianlancetaylor]

Fair enough.

[lattwood]

Not sure what to take away from that- should I make a PR so it always logs (fix the bug, which is opposite @robpike's rationale for freezing it), open a proposal for a louder warning/notice that net/rpc is frozen/support is deprecated, or do the go vulndb thing?

[ianlancetaylor]

I've already sent a change to make it clearer that the package is frozen.

I don't see why this is a vulnerability, so vulndb doesn't seem appropriate.

I recommend that you copy the package into your source tree, and edit it as you see fit. It doesn't depend on any internal standard library APIs, so copying it should be straightforward.