IPC-38: IPLD Resolver smoke test #64
Conversation
| /// This seems to be the only way, because Kademlia rightfully treats | ||
| /// incoming connections as ephemeral addresses, but doesn't have an | ||
| /// alternative exchange mechanism. | ||
| pub fn add_identified(&mut self, peer_id: &PeerId, info: &Info) { |
There was a problem hiding this comment.
TODO: Buffer these until bootstrapping is finished.
Created https://github.com/consensus-shipyard/ipc-agent/issues/70
aakoshh
force-pushed
the
ipc-38-resolver-test
branch
2 times, most recently
from
4a4d0db
to
cd520e4
Compare
aakoshh
force-pushed
the
ipc-38-resolver-test
branch
from
cd520e4
to
72faffd
Compare
|
|
||
| // Wait a little for the gossip to spread and peer lookups to happen, then another round of gossip. | ||
| // TODO: Wait on some condition instead of sleep. | ||
| tokio::time::sleep(Duration::from_secs(2)).await; |
There was a problem hiding this comment.
This have been shown to be a recurring issue when testing gossipsub-related protocols. >1s sync delay (which is the default heartbeat time) is the easy one, but IIRC we can probably listen or poll the libp2p host to see if it is bootrstapped. I don't know if this can be done easily in Rust, I did this once in Go.
(We can do something similar with the bootstrap delay above)
There was a problem hiding this comment.
Thank you for the tips. I can also add more events to show when things have progressed, and I have seen examples in the libp2p tests of a combination of a polling function and a timeout.
Closes consensus-shipyard/ipc#464
Smoke test exercising the simplest possible scenario of starting some nodes, bootstrapping from the 1st, putting some content in the store of the 2nd, resolving by the 3rd.
Example run:
RUST_LOG=debug cargo test -p ipc_ipld_resolver --test smokeThere are some non-ideal things left in the PR, to be fixed later:
But I think this is not bad to show that something works, with all the fixes that needed for it to happen, it's not a small PR.