Skip to content
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: TestTimeoutHandlerAndFlusher flaky on darwin-arm64-corellium #34573

Closed
bcmills opened this issue Sep 27, 2019 · 9 comments
Closed

net/http: TestTimeoutHandlerAndFlusher flaky on darwin-arm64-corellium #34573

bcmills opened this issue Sep 27, 2019 · 9 comments

Comments

@bcmills
Copy link
Member

@bcmills bcmills commented Sep 27, 2019

The new regression test added for #34439 just flaked twice on the darwin-arm64-corellium builder:

--- FAIL: TestTimeoutHandlerAndFlusher (0.14s)
    serve_test.go:6193: Status code mismatch
        got:  418
        want: 503
    serve_test.go:6198: Body mismatch
        got:  "line1\nline2\n"
        want: "TIMED OUT\n"
FAIL
FAIL	net/http	9.476s

The time.Sleep(timeout * 2) seems suspect,¹ although I'm not certain that's the root cause of the flakes.

(Also, I have no idea why the test server thinks it is a teapot. 😅)

¹ https://testing.googleblog.com/2008/08/tott-sleeping-synchronization.html

CC @bradfitz

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Sep 27, 2019

Let's just delete the whole test.

@odeke-em
Copy link
Member

@odeke-em odeke-em commented Sep 27, 2019

@odeke-em
Copy link
Member

@odeke-em odeke-em commented Sep 27, 2019

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 27, 2019

Change https://golang.org/cl/197757 mentions this issue: net/http: remove TestTimeoutHandlerAndFlusher due to flakes

@odeke-em
Copy link
Member

@odeke-em odeke-em commented Sep 27, 2019

I got some time in my ride and I've mailed https://go-review.googlesource.com/c/go/+/197757 to remove it.

@gopherbot gopherbot closed this in 5573885 Sep 27, 2019
@bcmills
Copy link
Member Author

@bcmills bcmills commented Sep 27, 2019

@gopherbot, please backport to Go 1.13: the flaky test was also backported.

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 27, 2019

Backport issue(s) opened: #34579 (for 1.13).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

@bcmills bcmills closed this Sep 27, 2019
@gopherbot
Copy link

@gopherbot gopherbot commented Sep 27, 2019

Change https://golang.org/cl/197719 mentions this issue: [release-branch.go1.13] net/http: remove TestTimeoutHandlerAndFlusher due to flakes

gopherbot pushed a commit that referenced this issue Sep 27, 2019
… due to flakes

Removes TestTimeoutHandlerAndFlusher due to flakes on
one of the builders due to timing issues.

Perhaps later, we might need to bring it back when we've
figured out the timing issues.

Updates #34573
Fixes #34579

Change-Id: Ia88d4da31fb228296144dc31f9a4288167fb4a53
Reviewed-on: https://go-review.googlesource.com/c/go/+/197757
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 5573885)
Reviewed-on: https://go-review.googlesource.com/c/go/+/197719
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
@pam4
Copy link

@pam4 pam4 commented Sep 27, 2019

@odeke-em, there were different failure modes:

  1. handler changes w.Header(); handler calls Flush; handler returns before timeout -> client can't see header changes;
  2. handler calls w.WriteHeader(someCode); handler calls Flush; handler returns before timeout -> client sees StatusOK instead of someCode;
  3. handler calls Flush; timeout occurs (after Flush but before handler returns) -> client sees StatusOK instead of StatusServiceUnavailable.

(In all cases the underlying WriteHeader was called twice.)
NewTestTimeoutHandler seems useful to reproduce those conditions.
To test for #1/#2 there's no need to delay the handler, just send the timeout after the client has finished.
To test for #3 you could have the handler flush, then send the timeout, then block on a channel until the client has finished.

Anyway, if everything except Flush is already tested elsewhere, maybe just failing the test if the ResponseWriter is a Flusher is enough.
I think it's safe to assume that TimeoutHandler will never support flush: even if we managed to unblock Flush on timeout, if it does anything at all it would hinder the ability to return 503 + msg as advertised.

Thanks for fixing the issue, btw!

@golang golang locked and limited conversation to collaborators Sep 26, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants