Eitu33

Yep that's how it has been implemented for ledger and executed ops, I specified "On finality".

Taking back this issue

Saw another one today: ``` 2022-09-23T09:33:14.448528Z INFO massa_bootstrap::client: Bootstrap from server 51.75.60.228:31245 failed. Your node will try to bootstrap from another server in 60s. 2022-09-23T09:34:14.450434Z INFO massa_bootstrap::client: Start bootstrapping from...

I suspected that this could be related to nodes trying to enter the network through other participants with lower configs than required which would result in a PoS bootstrap delay....

Note that this is a marginal case and seems to not happen often.

https://github.com/massalabs/massa/issues/3058#issue-1381991291 does not remember from what nodes he bootstrapped, but said it happened to him only once and was able to connect through non-initial nodes. https://github.com/massalabs/massa/issues/3058#issuecomment-1256015386 said that it happens...

Third one: 

Was able to reproduce with enhanced logs, investigating now: ``` 2022-09-26T09:51:31.800776Z INFO massa_node: Node version : TEST.14.7 2022-09-26T09:51:31.808357Z INFO massa_bootstrap::client: Start bootstrapping from 149.202.89.125:31245 2022-09-26T09:51:33.044330Z WARN massa_pos_exports::types: [main bootstrap] last...

Enhanced logs of a node acting as bootstrap server, first 2 succeeded last one failed (on client side): ``` 2022-09-26T12:48:44.215232Z WARN massa_bootstrap::server: (main bootstrap (server)) last streaming step: Started |...

Found where https://github.com/massalabs/massa/issues/3058#issuecomment-1257182893 is coming from. When a node tries to bootstrap, if final state changes are streamed because of a mid way ledger update, and PoS cycles are still...