net/http: error unwrapping broken on some transport errors #56435
Description
What version of Go are you using (go version)?
$ go version go version go1.19.2 linux/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/circleci/.cache/go-build" GOENV="/home/circleci/.config/go/env" GOEXE="" GOEXPERIMENT="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/circleci/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/circleci/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GOVCS="" GOVERSION="go1.19.2" GCCGO="gccgo" GOAMD64="v1" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/dev/null" GOWORK="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2218043753=/tmp/go-build -gno-record-gcc-switches"
What did you do?
Here's my repro that only seems to work on Linux: https://go.dev/play/p/k305YHkn2QM
You can run it a couple of times to get results like this:
Get "http://localhost:35633": write tcp 127.0.0.1:52368->127.0.0.1:35633: use of closed network connection
in chain: false
Get "http://localhost:35633": read tcp 127.0.0.1:52368->127.0.0.1:35633: use of closed network connection
in chain: true
Get "http://localhost:35633": read tcp 127.0.0.1:52368->127.0.0.1:35633: use of closed network connection
in chain: true
Get "http://localhost:35633": readLoopPeekFailLocked: read tcp 127.0.0.1:52368->127.0.0.1:35633: use of closed network connection
in chain: false
Get "http://localhost:35633": write tcp 127.0.0.1:52368->127.0.0.1:35633: use of closed network connection
in chain: false
What did you expect to see?
I expected net.ErrClosed to always be part of the error chain
What did you see instead?
It looks like for the write tcp and readLoopPeekFailLocked the error chain can't be unwrapped entirely.