fix: running queues after stop #322
Conversation
ghost
assigned 
License: MIT Signed-off-by: Alan Shaw <alan.shaw@protocol.ai>
alanshaw
force-pushed
the
fix/running-queues-after-stop
branch
from
281b2f0
to
fae1f15
Compare
|
The issue with this current approach is that the switch doesn't currently prohibit dials when it is stopped (which is why some tests are failing, they never start the switch). While libp2p currently prohibits dials when it's offline, it may be something that warrants changing in the future, libp2p/js-libp2p#341. It might be simpler to just ensure the target queue exists before adding it and starting it, to avoid the change in switch behavior. This is likely an edge case with running queues shutting down while the queues are draining. |
|
...but if the switch is stopped isn't it reasonable for it to disallow dials? I take the point on libp2p/js-libp2p#341 but should there instead be different modes of operation? e.g. "start in dial only mode" My issue is that #323 will guard against the edge case but it doesn't actually solve the issue of the node continuing to run after it has been "stopped". |
Yeah sorry, I confused the goal being to just fix #323. I am looking into an issue where there are connections staying open after close, even when the queues are stopped which is likely contributing to this problem. I do think a configuration of dialOnly or offline is the best route to go for supporting libp2p/js-libp2p#341 properly. |
I should have made it clearer. Do you think what's here is valuable? If so, I'm happy to do the work the fix up the tests. |
Yes, what if we had the dial manager initialize with |
|
Superceded by #324 |
resolves #321