Skip to content

chore(p2p): prefer tcp when discovering bootnodes#5406

Open
acud wants to merge 3 commits intomasterfrom
prefer-tcp
Open

chore(p2p): prefer tcp when discovering bootnodes#5406
acud wants to merge 3 commits intomasterfrom
prefer-tcp

Conversation

@acud
Copy link
Contributor

@acud acud commented Mar 20, 2026

Checklist

  • I have read the coding guide.
  • My change requires a documentation update, and I have done it.
  • I have added tests to cover my changes.
  • I have filled out the description and linked the related issues.

Description

This PR introduces a prioritization of TCP underlays over other types of underlays when connecting to bootnodes.

AI Disclosure

  • This PR contains code that has been generated by an LLM.
  • I have reviewed the AI generated code thoroughly.
  • I possess the technical expertise to responsibly review the code generated in this PR.

@acud acud self-assigned this Mar 20, 2026
@acud acud added enhancement enhancement of existing functionality autotls labels Mar 20, 2026
@acud acud requested a review from gacevicljubisa March 20, 2026 14:46
@gacevicljubisa
Copy link
Member

If I got it correctly, if bootnode has multiple underlays with TCP and WSS, and TCP for some reason is not connectable, currently it will never try other WSS address (because of the priority). This is beacuse in kademlia.go:832-835 - the callback returns (false, err) on any Connect failure (except ErrAlreadyConnected), and Discover propagates that error, aborting the loop. Would it be better that we skip and continue with next underlay?

@acud
Copy link
Contributor Author

acud commented Mar 21, 2026

Thanks @gacevicljubisa. Not sure what do you mean with this assumption. My understanding is that the bool in the callback return signature is stop, not continue, so returning false is fine and would continue to iterate over addresses. Please double check me on this. My understanding is that only returning true stops the loop, which happens in two places (either too many attempts or 3 bootnodes connected):

		if _, err := p2p.Discover(ctx, addr, func(addr ma.Multiaddr) (stop bool, err error) {
			loggerV1.Debug("connecting to bootnode", "bootnode_address", addr)
			if attempts >= maxBootNodeAttempts {
				return true, nil
			}
.....


			// connect to max 3 bootnodes
			return connected >= 3, nil
		});

@gacevicljubisa
Copy link
Member

gacevicljubisa commented Mar 23, 2026

Thanks @gacevicljubisa. Not sure what do you mean with this assumption. My understanding is that the bool in the callback return signature is stop, not continue, so returning false is fine and would continue to iterate over addresses. Please double check me on this. My understanding is that only returning true stops the loop, which happens in two places (either too many attempts or 3 bootnodes connected):

		if _, err := p2p.Discover(ctx, addr, func(addr ma.Multiaddr) (stop bool, err error) {
			loggerV1.Debug("connecting to bootnode", "bootnode_address", addr)
			if attempts >= maxBootNodeAttempts {
				return true, nil
			}
.....


			// connect to max 3 bootnodes
			return connected >= 3, nil
		});

When the callback returns (false, err) with a non-nil error, Discover propagates that error immediately and aborts the loop. The remaining addresses are never tried. Look at discover.go:57-59

I would suggest after Connect in kademlia.go:826 we check for p2p.ErrUnsupportedAddresses:

	if errors.Is(err, p2p.ErrUnsupportedAddresses) {
		k.logger.Debug("bootnode address transport not supported, skipping", "bootnode_address", addr)
		return false, nil
	}

And also, not to propage error from Connect at all in kademlia.go:831-838

	if err != nil {
		if errors.Is(err, p2p.ErrAlreadyConnected) {
			k.logger.Debug("bootnode already connected", "bootnode_address", addr)
			return false, nil
		}
		k.logger.Error(err, "connect to bootnode failed", "bootnode_address", addr)
		return false, nil
	}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

autotls enhancement enhancement of existing functionality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants