net/http: apparent deadlocks in TestDisableKeepAliveUpgrade on longtest builders #43073
Comments
This regression was partially masked in the builders by #42942. |
Hmm, interesting that it only occurs on Windows. Looks like the |
Nothing stands out, the test may be surfacing an unrelated regression. |
Actually I'm going to push up a change that may fix it. |
1. The test now checks the response status code. 2. The transport does not set `Connection: Close` if DisableKeepAlive is set but the request is a HTTP/1.1 protocol upgrade request. Updates golang#43073
1. The test now checks the response status code. 2. The transport does not set `Connection: Close` if DisableKeepAlive is set but the request is a HTTP/1.1 protocol upgrade request. Updates golang#43073
1. The test now checks the response status code. 2. The transport does not set `Connection: Close` if DisableKeepAlive is set but the request is a HTTP/1.1 protocol upgrade request. Updates golang#43073
Opened #43086 |
1. The test now checks the response status code. 2. The transport has been changed to not set `Connection: Close` if DisableKeepAlive is set but the request is a HTTP/1.1 protocol upgrade. Updates golang#43073
1. The test now checks the response status code. 2. The transport has been changed to not set `Connection: Close` if DisableKeepAlive is set and the request is a HTTP/1.1 protocol upgrade. Updates golang#43073
Change https://golang.org/cl/276375 mentions this issue: |
1. The test now checks the response status code. 2. The transport has been changed to not set `Connection: Close` if DisableKeepAlive is set and the request is a HTTP/1.1 protocol upgrade. Updates golang#43073
1. The test now checks the response status code. 2. The transport has been changed to not set `Connection: Close` if DisableKeepAlive is set and the request is a HTTP/1.1 protocol upgrade. Updates golang#43073
1. The test now checks the response status code. 2. The transport has been changed to not set "Connection: Close" if DisableKeepAlive is set and the request is a HTTP/1.1 protocol upgrade. Updates golang#43073
1. The test now checks the response status code. 2. The transport has been changed to not set "Connection: Close" if DisableKeepAlive is set and the request is a HTTP/1.1 protocol upgrade. Updates golang#43073
1. The test now checks the response status code. 2. The transport has been changed to not set "Connection: Close" if DisableKeepAlive is set and the request is a HTTP/1.1 protocol upgrade. Updates golang#43073
1. The test now checks the response status code. 2. The transport has been changed to not set "Connection: Close" if DisableKeepAlive is set and the request is a HTTP/1.1 protocol upgrade. Updates #43073 Change-Id: I9977a18b33b8747ef847a8d11bb7b4f2d8053b8c GitHub-Last-Rev: f809ceb GitHub-Pull-Request: #43086 Reviewed-on: https://go-review.googlesource.com/c/go/+/276375 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Trust: Dmitri Shuralyov <dmitshur@golang.org>
Thanks for looking into this @nhooyr. There haven't been instances of this failure since CL 276375 was submitted, although given it happened infrequently earlier, that's not a definitive signal. Do you know if anything more needs to be done for this issue, or is it a matter of waiting for some more data before closing? I'll add okay-after-beta1 since I'm not seeing something here that needs to block beta 1. Please comment if I missed something. |
I didn't notice anything else that could cause it so yes I'd agree that it is a matter of waiting for some more data. |
Damn, that's unfortunate. Hope I have some time this weekend to investigate but if not, I think we should just revert my changes & the test and I'll try and reproduce myself first. |
2020-12-07T21:01:46-7ad6596/windows-amd64-longtest
2020-12-04T08:49:16-b67b7dd/windows-amd64-longtest
2020-12-02T16:43:58-10240b9/windows-amd64-longtest
Marking as release-blocker for Go 1.16: this is a new test, merged Dec. 1 in CL 213277 for #36381.
CC @bradfitz @nhooyr @neild @fraenkel @golang/release
The text was updated successfully, but these errors were encountered: