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

Jump to bottom

net: TestDialTimeout failures with connect: connection refused #56876

Closed
gopherbot opened this issue Nov 21, 2022 · 6 comments
Closed

net: TestDialTimeout failures with connect: connection refused #56876

gopherbot opened this issue Nov 21, 2022 · 6 comments
Assignees
@bcmills
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Testing An issue that has been verified to require only test changes, not just a test failure.
Milestone
Go1.22

Comments

@gopherbot
Copy link

gopherbot commented Nov 21, 2022 •
edited by bcmills 

#!watchflakes
post <- pkg == "net" && test == "TestDialTimeout" && `connect: connection refused`

Issue created automatically to collect these failures.

Example (log):

--- FAIL: TestDialTimeout (0.00s)
    timeout_test.go:89: #5: dial tcp 127.0.0.1:0: connect: connection refused

— watchflakes
@gopherbot gopherbot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Nov 21, 2022
@gopherbot
Copy link
Author

Found new dashboard test flakes for:

#!watchflakes
post <- pkg == "net" && test == "TestDialTimeout"
2022-11-17 21:15 linux-amd64 go@1f4394a0 net.TestDialTimeout (log) 
--- FAIL: TestDialTimeout (0.00s)
    timeout_test.go:89: #5: dial tcp 127.0.0.1:0: connect: connection refused

— watchflakes

@bcmills bcmills changed the title net: TestDialTimeout failures net: TestDialTimeout failures with connect: connection refused Nov 21, 2022
@bcmills
Copy link
Contributor

bcmills commented Nov 21, 2022

See previously #22896, #13144, #11872.
(CC @ianlancetaylor @neild)

@bcmills bcmills added this to the Backlog milestone Nov 21, 2022
@bcmills
Copy link
Contributor

bcmills commented Nov 29, 2022

https://storage.googleapis.com/go-build-log/4a3b7751/linux-amd64-boringcrypto_9850cae1.log (a TryBot on https://go.dev/cl/453602)

@gopherbot
Copy link
Author

Change https://go.dev/cl/524055 mentions this issue: net: avoid internal hooks in TestDialTimeout

@bcmills bcmills modified the milestones: Backlog, Go1.22 Aug 29, 2023
@bcmills bcmills self-assigned this Aug 29, 2023
@bcmills bcmills added the Testing An issue that has been verified to require only test changes, not just a test failure. label Aug 29, 2023
@gopherbot
Copy link
Author

Change https://go.dev/cl/524455 mentions this issue: net: skip TestDialTimeout subtests on Windows if Dial returns WSAECONNREFUSED

gopherbot pushed a commit that referenced this issue Aug 30, 2023
@gopherbot
net: skip TestDialTimeout subtests on Windows if Dial returns WSAECON…
a8d45a7 
…NREFUSED

Since we have only seen this failure mode on windows/arm64,
we do not skip on the Go project's windows/amd64 builders
so that we will be more likely to find out whether this failure mode
is specific to arm64.

Also simplify the ECONNRESET check, since I've remembered that the
error_*_test.go files exist.

Fixes #62359.
Updates #56876.

Change-Id: I17bd678486f3d3ec3363a45986a711f570b013d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/524455
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
@gopherbot
Copy link
Author

Change https://go.dev/cl/524595 mentions this issue: net: retry TestDialTimeout subtests with progressively shorter timeouts

gopherbot pushed a commit that referenced this issue Aug 30, 2023
@gopherbot
net: retry TestDialTimeout subtests with progressively shorter timeouts
51ed3cb 
The LUCI builders seem to show that the failure mode in #62359 is not
specific to windows/arm64, but it occurs to me that we ought to be
able to eventually retry by making the timeout so short that the
remote end can't possibly respond in time (discounting the possibility
that the kernel itself might short-circuit the loopback address).

For #62377.
Updates #62359.
Updates #56876.

Change-Id: I1fb5fa4f2a5d2cfe35465f34248ed9a035f91f4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/524595
Reviewed-by: Damien Neil <dneil@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bcmills bcmills

Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Testing An issue that has been verified to require only test changes, not just a test failure.
Projects
Test Flakes
Status: Done
Milestone
Go1.22
Development

No branches or pull requests
2 participants
@bcmills @gopherbot