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

graphql: fix spurious travis failure #22166

Merged
merged 2 commits into from
Jan 13, 2021
Merged

Conversation

holiman
Copy link
Contributor

@holiman holiman commented Jan 13, 2021

In go 1.14, the graphql tests runs really fast:

go test . -run TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful -v  --count 20
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.00s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.00s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.00s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.00s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.00s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.00s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.00s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.00s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.00s)

But sometimes they fail:

=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
    TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful: graphql_test.go:161: could not post: Post "http://127.0.0.1:9393/graphql": EOF

In go 1.15, they run slow. But

go test . -run TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful -v  --count 20
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.53s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.58s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.51s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.50s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.51s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.50s)
=== RUN   TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful
--- PASS: TestGraphQLHTTPOnSamePort_GQLRequest_Unsuccessful (0.56s)

But they don't spuriously fail!

So the delay seems to be working. What is the delay? The delay is improved in this commit: golang/go@f0c9ae5 , and digging into the back-story a bit, it can be surmised that there's a race between closing connecttions, and that there may be active connections that get bit by it. It seems that 1.14 suffers from this. Maybe a straggling 'close' or 'reset' is still on the network when the next connection is made.

Whatever the reason, it seems that a working fix is to not use the same port every time, but randomize it a bit. With this PR, I no longer trigger the error on go 1.14.

@holiman holiman requested a review from gballet as a code owner January 13, 2021 11:54
Copy link
Member

@MariusVanDerWijden MariusVanDerWijden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

WSHost: "127.0.0.1",
WSPort: 9393,
WSPort: port,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not use port zero here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. Indeed...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, PTAL

})
if err != nil {
t.Fatalf("could not create node: %v", err)
}
if !gqlEnabled {
return stack
}
createGQLService(t, stack, fmt.Sprintf("127.0.0.1:%d", port))
createGQLService(t, stack, node.DefaultHTTPEndpoint())
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bleh, I'll fix this

@fjl fjl merged commit 96157a8 into ethereum:master Jan 13, 2021
bulgakovk pushed a commit to bulgakovk/go-ethereum that referenced this pull request Jan 26, 2021
The tests sometimes failed with certain go versions because
the behavior of http.Server.Shutdown changed over time. A bug
that was fixed in Go 1.15 could cause active connections on unrelated
servers to close unexpectedly. This is fixed by avoiding use of the
same port number in all tests.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants