Unspecified initial firing of event.EvtLocalAddressesUpdated

[aschmahmann]

Perhaps this issue belong in go-libp2p-core, but it's not obvious to me whether event.EvtLocalAddressesUpdated should be fired when initially creating a Host.

For example, the BasicHost will fire this event in transitioning from nil addresses to found addresses during its first run of the background function

go-libp2p/p2p/host/basic/basic_host.go

Line 517 in eb4cca1

emitAddrChange(curr, lastAddrs)

However, because this is a background event this may occur before or after any systems that use a host have been created. For uses such as testing which likely depend on knowing exactly how and when events are fired this can be a bit of a mine field.

For example, #936 and #956 introduced the use of the netroute library in determining host addresses. As netroute results in some OS calls that can take time this made tests that assumed event.EvtLocalAddressesUpdated was not fired between creating the Host and creating the subsystem that depends on the Host fail.

It seems to me like either we should make event.EvtLocalAddressesUpdated not be fired when the BasicHost first gets an address or we should make this event Stateful. Leaving the event in this middle ground makes testing difficult due to asynchronicity issues.

@petar @willscott @raulk

[lthibault]

It seems to me like either we should make event.EvtLocalAddressesUpdated not be fired when the BasicHost first gets an address or we should make this event Stateful.

I currently rely on this behavior, so I would strongly prefer the Stateful approach.

However, because this is a background event this may occur before or after any systems that use a host have been created.

I can also confirm that this is a bit of a hassle. In my own usage, I've resorted to first starting the Host without any listen addresses, and then manually calling l.Network().Listen(addrs...) to generate EvtLocalAddressesUpdated. Having a stateful event subscription would allow me to tear out quite a bit of convoluted code.

[willscott]

making it Stateful seems like the right way to go in terms of how i'd think of it. Makes the naming of the event a bit nonintuitive, but still probably the best compromise

[marten-seemann]

I checked that the initial listen addresses are emitted as an event, and this is reliable, since with #1147 the event is stateful. I'd like to add an integration test for this before closing this issue though, since this is a pretty important behavior that users rely on. PR incoming.