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

fix: Close conn in quic listener when wrapping fails #2852

Merged
merged 3 commits into from
Jul 1, 2024

Conversation

MarcoPolo
Copy link
Collaborator

When wrapping a quic connection into a transport.CapableConn we wouldn't always close the underlying connection if wrapping failed. This fixes that and adds some tests to ensure all transports do this properly.

I believe this closes #2841

}

// No error yet, let's continue using the conn
s.SetReadDeadline(time.Now().Add(1 * time.Second))
Copy link
Member

Choose a reason for hiding this comment

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

We can keep this 10 seconds. It will error before that any way.

Comment on lines +720 to +722
_, err := client.NewStream(ctx, server.ID(), ping.ID)
require.Error(t, err)
require.False(t, errors.Is(err, context.DeadlineExceeded), "expected error to be not be context deadline exceeded")
Copy link
Member

Choose a reason for hiding this comment

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

This will succeed if the implementation is using lazy multistream negotiation, right?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

In which case the require.Error will fail. I haven't seen that happen which is probably because we require the identify to happen before returing a new stream (a separate issue). For now I think let's leave this as is and when we change the Identify/NewStream interaction we can update this test.

Comment on lines +699 to +700
if tc.Name == "WebRTC" {
continue // WebRTC doesn't have a connection when we block so there's nothing to close
Copy link
Member

Choose a reason for hiding this comment

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

Should we test this, NewStream on client will still fail, which is what we want. It'll fail with DeadlineExceeded though

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I don't think we should. It's not testing what we think. The only thing it tests is whether the server ignores us and we hit a deadline.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe we could make another tests that just focuses on that behavior for WebRTC though?

Copy link
Member

Choose a reason for hiding this comment

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

It would test that if the respurce manager blocks no connection is established. But we can handle that separately. I am fine with keeping it as is.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@MarcoPolo MarcoPolo merged commit 9b138c2 into master Jul 1, 2024
11 checks passed
@sukunrt
Copy link
Member

sukunrt commented Jul 2, 2024

Did you merge this instead of squash and merge? 😅

@MarcoPolo
Copy link
Collaborator Author

Unfortunately yes. Not on purpose. I feel like the defaults might have changed.

@nisdas
Copy link

nisdas commented Jul 3, 2024

When will this PR be included in a new release ?

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.

Memory Leak With Go-Libp2p
3 participants