You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OrbitDB has two peers connecting to one another and sharing messages using Libp2p and custom protocols. To initiate the message exchange, OrbitDB relies on the event subscription-change by attaching a listener to it. When fired, the listener will dial a protocol from peerA from peerB and initiate an exchange of data via streams.
When bootstrapping peerA's address in peerB, subscription-change fires reliably. However, when a discovery mechanism is used (we have been using mdns for local network discovery) and the peerB dials peerA manually, subscription-change becomes unreliable, sometimes firing, sometimes not.
The dialling will ensure all relevant peers are connected in a similar fashion to when bootstrapping on initialization; Orbiter1, Orbiter2, Lander1, Lander2. However, subscription-change will fail which will result in timeout errors such as:
Error: Timeout of 30000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (~/orbitdb/voyager/test/e2e-browser.test.js)
The assumption would be that whether bootstrapped or dialled manually, the subscription-change event would fire regardless.
The text was updated successfully, but these errors were encountered:
Version:
2.1.9
Platform:
Linux 6.9.3-76060903-generic #202405300957
172117465722.04~abb7c06 SMP PREEMPT_DYNAMIC Wed J x86_64 x86_64 x86_64 GNU/LinuxSubsystem:
Pubsub (GossipSub)
Severity:
Medium
Description:
OrbitDB has two peers connecting to one another and sharing messages using Libp2p and custom protocols. To initiate the message exchange, OrbitDB relies on the event subscription-change by attaching a listener to it. When fired, the listener will dial a protocol from peerA from peerB and initiate an exchange of data via streams.
When bootstrapping peerA's address in peerB, subscription-change fires reliably. However, when a discovery mechanism is used (we have been using mdns for local network discovery) and the peerB dials peerA manually, subscription-change becomes unreliable, sometimes firing, sometimes not.
Watching the pipePeerReadStream function in GossipSub, it appears that the stream doesn't contain anything and the data handling is completely skipped, giving the appearance that the event doesn't fire when, in fact, it does but it skips over much of the function because there is no data to read.
Steps to reproduce the error:
Prerequisites:
To see a successful test run:
In terminal 1 start the relay:
In terminal 2 start the first pinner server:
In terminal 3 start the second pinner server:
In terminal 4, run the unit tests:
or
All tests should run successfully.
To see subscription-change fail:
Kill Orbiter1 and Orbiter2
In src/lib/libp2p-config.js, uncomment this line and this line to enable local network discovery. Comment out the node bootstrapping. Config should now look like:
In src/daemon.js, add the following after line 55:
In terminal 1 start the relay:
In terminal 2 start the first pinner server:
In terminal 3 start the second pinner server:
In terminal 4, run the unit tests:
or
The dialling will ensure all relevant peers are connected in a similar fashion to when bootstrapping on initialization; Orbiter1, Orbiter2, Lander1, Lander2. However, subscription-change will fail which will result in timeout errors such as:
The assumption would be that whether bootstrapped or dialled manually, the subscription-change event would fire regardless.
The text was updated successfully, but these errors were encountered: