Code change:
} } <del> // TestClientReceivedGOAWAY tests the in-flight watch requests will not be affected and new requests use a // connection after client received GOAWAY, and server response watch request with GOAWAY will not break client // watching body read. func TestClientReceivedGOAWAY(t *testing.T) { const ( urlNormal          = "/normal" urlWatch           = "/watch" urlGoaway          = "/goaway" urlWatchWithGoaway = "/watch-with-goaway" ) </del> <ins> const ( urlGet             = "/get" urlPost            = "/post" urlWatch           = "/watch" urlGetWithGoaway   = "/get-with-goaway" urlPostWithGoaway  = "/post-with-goaway" urlWatchWithGoaway = "/watch-with-goaway" ) </ins> <del> const ( // indicate the bytes watch request will be sent // used to check if watch request was broke by GOAWAY watchExpectSendBytes = 5 ) </del> <ins> var ( // responseBody is the response body which test GOAWAY server sent for each request, // for watch request, test GOAWAY server push 1 byte in every second. responseBody = []byte("hello") // responseBodySize is the size of response body which test GOAWAY server sent for watch request, // used to check if watch request was broken by GOAWAY frame. responseBodySize = len(responseBody) // requestPostBody is the request body which client must send to test GOAWAY server for POST method, // otherwise, test GOAWAY server will respond 400 HTTP status code. requestPostBody = responseBody ) // newTestGOAWAYServer return a test GOAWAY server instance. func newTestGOAWAYServer() (*httptest.Server, error) { </ins> watchHandler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { timer := time.NewTicker(time.Second) <ins> defer timer.Stop() </ins> w.Header().Set("Transfer-Encoding", "chunked") w.WriteHeader(200)

Related discussion:
text: What happened: We enabled feature in our large-scale cluster, and we found client(Kubelet) may got error(500 http code response) like after received GOAWAY frame. I had already re-produce this bug and open an in golang repo. So far I think this bug only occur with a small probability when client request server in high concurrency use a same httpclient instance, and it's a golang sdk bug in http client. Before I solved this issue, I suggest do NOT enable GOAWAY() feature. As it's a golang sdk bug(currently I known and doubt) in http client, revert GOAWAY feature(codes) is not necessary.
cc
/sig api-machinery
Thanks for the report.
Based on not setting the field, I think it defaults that way, so that's good. We will leave the option and filter so that when golang updates its client, we will have a simple way to turn it on and execute it.
Sure. I am trying to fix the golang http client issue and will update progress at . After golang http client issue fixed, I will add more concurrent test cases to see if there are any other bugs may occur by GOAWAY feature. BTW, we still enable GOAWAY feature in our production cluster, because there is no any evidence told us this error will influence SLO, as all most components(kubelet, controller-manager, scheduler) is controller work mode and will re-try after got error. /assign
Golang version or required, which will release at 07/01/2020.
Kubernetes v1.19(or master branch) now is using golang 1.15, and golang 1.15 has fixed the issue. And is on going. Let me add more test cases to ensure the error will not happen again.
I think we should re-open this issue because of . /re-open