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: deflake more tests using backoff #24580
Comments
Hmmm. Actually, looking at the dashboard, it appears that when the network gets really flaky, enough of these backoffs trigger that the package net tests time out instead. So it helps a little...but not enough. Sigh. We could increase the timeout for package net, perhaps? Better a slow pass than a fast flaky failure. @bradfitz any opinions? |
If these individual tests take very long due to a flaky network, I wonder if a higher |
Good idea. And none of these tests are marked as parallel at all. So two things to do here: Add retries to TestLookupCNAME, and mark all these tests as parallel. |
Change https://golang.org/cl/103655 mentions this issue: |
The back off approach is fine. I'd also like to see some isolation between tests using the infrastructure and tests using the local system. FWIW, I have a plan to improve testing on DNS stub resolver after landing CL 102875, perhaps in Go 1.12 development cycle. It will use mock DNS servers for testing on connection setup and RR lookup APIs and will drop unnecessary dependence on the infrastructure. |
Apply the same approach as in CL 102397. Updates #24580 Change-Id: I65955f62a70807c87216519d03f3643a8f214dee Reviewed-on: https://go-review.googlesource.com/103655 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change https://golang.org/cl/103975 mentions this issue: |
Reverted. Reopening. |
@feliixx thanks for working on this. Are you up for diagnosing and fixing the data race? |
Change https://golang.org/cl/104677 mentions this issue: |
In https://golang.org/cl/102397, I added some retry with backoff loops to some flaky net tests. It appears to have helped the build dashboard. I mentioned in the commit message that we could use the same approach for other flaky tests that we see. Looking at build.golang.org, it looks like TestLookupCNAME could use the same treatment.
This would be a great starter fix for someone looking to contribute. Or maybe @odeke-em? :)
The text was updated successfully, but these errors were encountered: