feat(chainsync): multi-peer client registry with failover and dedupe
Signed-off-by: Chris Gianelloni <[email protected]>
Signed-off-by: Chris Gianelloni <[email protected]>
Bump network and consensus for node-10.6.2
Signed-off-by: Chris Gianelloni <[email protected]>
Signed-off-by: Chris Gianelloni <[email protected]>
Signed-off-by: Chris Gianelloni <[email protected]>
TxBodyContent refactoring related fixes
chore(onchain): remove 17 aiken warnings
This was preventing the offers to be released. This should not be needed as soon as we have implemented eb announcements. Then, the point would already be there, or the fetching logic should have not decided to download an unknown EB.
Only check completeness based on just inserted txHashes. Unfortunately we don't have JSON1 functions available in the presently available sqlite build, but this would be an even more efficient way to do this.
The LeiosDb now stores the principal information which txs we already have, across all ebs (n:m). The storing and later copying from the intermediate in-memory state is not needed anymore.
The previous `die` call was not showing up properly in the observability stack. This now gives at least the chance to be visible as a big fat error :x:
`die` just raises an exception and is not easily picked up by the observability stack
Signed-off-by: Chris Gianelloni <[email protected]>
Moves the notification mechanism into the `LeiosDbHandle` to allow convenient access from the block forging loop in the `NodeKernel` and simplify the issuance of notifications by keeping it local to the leios db (to become the `LeiosEBStore`?). With these changes, the forged endorser block bodies are submitted through the network :tada: What do you think of the notification mechanism via `TChan`?