New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
net/http: TestTransportAndServerSharedBodyRace failures with Proxy copy error
#58398
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Comments
gopherbot
added
the
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
label
Feb 7, 2023
Found new dashboard test flakes for:
2023-02-07 22:22 linux-amd64-clang go@9565d990 net/http.TestTransportAndServerSharedBodyRace (log)
|
bcmills
changed the title
net/http: TestTransportAndServerSharedBodyRace failures
net/http: TestTransportAndServerSharedBodyRace failures with Feb 8, 2023
Proxy copy error
Found new dashboard test flakes for:
2023-03-08 21:46 linux-amd64 go@4df95d51 net/http.TestTransportAndServerSharedBodyRace (log)
|
bcmills
added
the
Testing
An issue that has been verified to require only test changes, not just a test failure.
label
Sep 11, 2023
bcmills
removed
the
Testing
An issue that has been verified to require only test changes, not just a test failure.
label
Sep 11, 2023
Change https://go.dev/cl/527196 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Sep 13, 2023
As far as I can tell, some flakiness is unavoidable in tests that race a large client request write against a server's response when the server doesn't read the full request. It does not appear to be possible to simultaneously ensure that well-behaved clients see EOF instead of ECONNRESET and also prevent misbehaving clients from consuming arbitrary server resources. (See RFC 7230 §6.6 for more detail.) Since there doesn't appear to be a way to cleanly eliminate this source of flakiness, we can instead work around it: we can allow the test to adjust the hard-coded delay if it sees a plausibly-related failure, so that the test can retry with a longer delay. As a nice side benefit, this also allows the tests to run more quickly in the typical case: since the test will retry in case of spurious failures, we can start with an aggressively short delay, and only back off to a longer one if it is really needed on the specific machine running the test. Fixes #57084. Fixes #51104. For #58398. Change-Id: Ia4050679f0777e5eeba7670307a77d93cfce856f Cq-Include-Trybots: luci.golang.try:gotip-linux-amd64-longtest-race,gotip-linux-amd64-race,gotip-windows-amd64-race Reviewed-on: https://go-review.googlesource.com/c/go/+/527196 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Damien Neil <dneil@google.com> Auto-Submit: Bryan Mills <bcmills@google.com>
I believe this is fixed as of CL 527196. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Issue created automatically to collect these failures.
Example (log):
— watchflakes
The text was updated successfully, but these errors were encountered: