5

In our parachain setup we have one healthy collator node producing blocks. I tried to add two bootnodes and one collator to the set (all of them connecting to the existing collator). So for the bootnodes and the other collator, all of them were specifying the first healthy collator as "bootnode".

All the nodes discover each other, so they show 3 peers and, calling the RPC method system.peers() on each of them shows that they are the correct ones.

The problem comes when nor the new collator (which is part of the invulnerable set) or the other two nodes, show activity in the network as the existing collator does (i.e. they are stuck in an old block). So it appears to me to be like a stalled subset of nodes. Inspecting the RPC system.health() on the healthy node shows:

{
  peers: 3
  isSyncing: false
  shouldHavePeers: false
}

So that calls my attention: shouldHavePeers is false, while in the other 3 nodes is true. Does anyone know what exactly shouldHavePeers means, why is it false, and how to make the node axtually accept the other peers ? Any help will be much appreciated!

EDIT: I know from here that should_have_peers "Might be false for local chains or when running without discovery". This doesn't help too much, since it is not a Local network and we are not specifically running without discovery.

EDIT 2: system.chainType is Live for all the nodes.

3
  • Could you share the result of the rpc query system.chainType ? Commented Aug 25, 2022 at 9:52
  • 1
    Hey, thanks for commenting, the chain type is Live (I've updated my post). Anyway We managed to make them peer but we are not really sure how. I will try to elaborate an answer to close the question. Commented Aug 30, 2022 at 11:12
  • Any news about how you find the solution?
    – Alex Bean
    Commented Dec 21, 2022 at 16:50

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.