Check if leader was found in between network requests

[masnax]

We send a request to multiple peers concurrently to ask if they are the leader. They themselves may be the leader, or they may report who they think is the leader. We then try to reach out to whoever they think is the leader.

It is possible that we are are already talking to the leader concurrently with asking a different node who the leader is, so in such cases we don't need to send further network requests and can return early by checking if we have already found the leader in another goroutine.

[cole-miller]

We already have some logic along these lines---the investigating goroutines share a parent Context:

go-dqlite/internal/protocol/connector.go

Line 131 in 8145904

ctx, cancel := context.WithCancel(ctx)

Which is passed into connectAttemptOne:

go-dqlite/internal/protocol/connector.go

Line 168 in 8145904

protocol, leader, err := c.connectAttemptOne(ctx, server.Address, log)

And this context is cancelled as soon as we get a connection to the leader:

go-dqlite/internal/protocol/connector.go

Lines 214 to 219 in 8145904

	protocol, ok := <-protocolChan
	if !ok {
	return nil, ErrNoAvailableLeader
	}
	cancel()

So this change might be redundant, if I'm not missing something.

[masnax]

So this change might be redundant, if I'm not missing something.

Ah, looks like this one is a bug on our end then!

I was doing 2 things incorrectly here:

• I was counting the calls to the DialFunc instead of the calls that make it through to the other side. With the context, the cancellation won't manifest until much later.
• microcluster is not correctly passing the context through as it uses tls.DialWithDialer which internally uses context.Background(). Hence why I saw an improvement there, but now checking with dqlite-demo I don't see the same improvement.