-
Notifications
You must be signed in to change notification settings - Fork 18k
net/http: TestHijackAfterCloseNotifier failures #56275
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
Comments
Found new dashboard test flakes for:
2022-10-14 12:48 openbsd-arm64-jsing go@5fde02e3 net/http.TestHijackAfterCloseNotifier (log)
|
The (attn @neild) |
Found new dashboard test flakes for:
2022-12-06 18:32 darwin-amd64-race go@dfd13ce5 net/http.TestHijackAfterCloseNotifier (log)
|
Found new dashboard test flakes for:
2022-12-21 03:49 darwin-amd64-race go@78fc8107 net/http.TestHijackAfterCloseNotifier (log)
|
This comment was marked as off-topic.
This comment was marked as off-topic.
Found new dashboard test flakes for:
2023-04-04 07:16 darwin-amd64-12_0 go@56e900d9 net/http.TestHijackAfterCloseNotifier (log)
|
No-update update: Looked at this for a bit. Could not replicate on darwin-amd64-race builder. Could not find a plausible explanation for the flake. Admitting defeat for the moment. |
@neild, I wonder if the cluster of If so, then in order to reproduce it you might have to run the |
Hmm, or it could be a timing issue (which could be harder to reproduce in isolation because of differences in CPU/disk/network/syscall load). For example, in |
Hmm. I guess the “stray dial” theory doesn't apply in this case, because both client requests are getting an |
The client returns the idle connection to the pool before returning from RoundTrip, exactly to ensure that a followup request picks it up: Maybe something is happening that causes that first connection to close before it gets reused? |
Ah, that's the clue! The call to I can reproduce this failure mode on Linux by injecting (Why 100ms? Because it's somewhat longer than |
That same race seems to account for a large number of
And a couple of additional failures that have not yet been reported by Also related are:
(CC @paulzhol) |
Change https://go.dev/cl/483116 mentions this issue: |
Aha! Nice catch. Perhaps we should just disable the |
Issue created automatically to collect these failures.
Example (log):
— watchflakes
The text was updated successfully, but these errors were encountered: