BUG: extraneous peer:connect event emitted when dialer reconnects

[chafey]

• Version: 0.29.0
• Platform: Linux 1c087b494e39 5.4.0-7642-generic Improve libp2p config #46159862870720.04~040157c-Ubuntu SMP Fri Aug 28 18:02:16 UTC x86_64 GNU/Linux
• Subsystem:

Type: Bug

Severity: Medium

Description: My listener is receiving two peer:connect events when a dialer reconnects, I am expecting only one

Steps to reproduce the error:

1. Start example/chat/listener
2. Start example/chat/dialer. Observe that a single connected to: message is logged on the listener
3. Terminate example/chat/listener with control-c
4. Start example/chat/listener - observe that two connected: messages are logged on the listener while only one is expected

More info:
In this scenario, I only ever receive one peer:disconnect event and only see one connection in connectionManager.size. I suspect there is in fact just one connection established (which is correct) but for some reason two peer:connect messages are emitted, one for a phantom connection?

[vasco-santos]

Hey @chafey

Thanks for reaching out. This is a side effect of #647 and we should improve this logic with the work in #744

I did a small debugging on this and what is happening behind the scenes is:

• the dialer does the initial dial to the listener
• the connection is established between both parties and the identify protocol runs
• the dialer gets to know a second address of the listener
  • /ip4/127.0.0.1/tcp/10333/p2p/QmcrQZ6RJdpYuGvZqD5QEHAv6qX4BrQLJLQPQUrTrzdcgm
  • /ip4/192.168.1.120/tcp/10333/p2p/QmcrQZ6RJdpYuGvZqD5QEHAv6qX4BrQLJLQPQUrTrzdcgm
• the listener stops
• the dialer gets disconnected from the peer and keeps trying to connect to peers from the AddressBook (the listener is the only peer it knows)
• the listener starts again
• the dialer will attempt to dial the listener using the 2 known addresses for it
  • they both succeed at the same time as they are the same address... no time for the dialer to abort the second dial

The connectionManager will in fact have size one, but there are two open connections to the peer. More than improving the connection events per #647 we will work on not announcing private addresses, unless explicitly. This would result in the dialer only knowing one address for the peer, the one used to dial.

Shortly, we should take care of this in #744

[maschad]

This should be fixed, closing due to staleness