C’est normal, mon nœud rejette ton bloc, mais ton nœud ne va pas rejeter ton propre bloc ^^
D’ailleurs, je comprends pas comment ça se passe pour vos dates, moi c’est :
docker run --rm --entrypoint date duniter/duniter-v2s-gdev:latest && date
Mon Jul 22 14:52:42 UTC 2024
Mon Jul 22 14:52:42 UTC 2024
Moi j’ai beaucoup beaucoup de blocks rejetés tous issus du même noeud apparemment :
2024-07-22 13:45:57 💔 Verification failed for block 0x782eb0e4b455359874df7618fbb45d7cb660daadffd04c97176bd5adfe69a0ce received from (12D3KooWAikpy6szmM7QW5QYEFqjiiWYJ3AXLU448htzFLqam2Qr): "Header 0x782eb0e4b455359874df7618fbb45d7cb660daadffd04c97176bd5adfe69a0ce rejected: too far in the future"
2024-07-22 13:47:57 💔 Verification failed for block 0x821a6aaca9837875e8a8ef3e3cd220cee8f4729da280a90f15681be07ac7146f received from (12D3KooWAikpy6szmM7QW5QYEFqjiiWYJ3AXLU448htzFLqam2Qr): "Header 0x821a6aaca9837875e8a8ef3e3cd220cee8f4729da280a90f15681be07ac7146f rejected: too far in the future"
2024-07-22 13:48:10 💔 Verification failed for block 0xf4308ab03df4aa36611889dcf23a351566ebab32f5e6c6a4d309e61024843561 received from (12D3KooWAikpy6szmM7QW5QYEFqjiiWYJ3AXLU448htzFLqam2Qr): "Header 0xf4308ab03df4aa36611889dcf23a351566ebab32f5e6c6a4d309e61024843561 rejected: too far in the future"
2024-07-22 13:49:15 💔 Verification failed for block 0xd4808f2d1e9dcf1276bcfa365cd76f84f84774f22935b5989f89bbe878b05325 received from (12D3KooWAikpy6szmM7QW5QYEFqjiiWYJ3AXLU448htzFLqam2Qr): "Header 0xd4808f2d1e9dcf1276bcfa365cd76f84f84774f22935b5989f89bbe878b05325 rejected: too far in the future"
Le coupable serait donc un noeud identifié par 12D3KooWAikpy6szmM7QW5QYEFqjiiWYJ3AXLU448htzFLqam2Qr ?
EDIT : j’ai ces traces dans mes logs depuis le 21 mai 2024.
Ça fait une piste à explorer, peut-être liée à un problème d’horloge, mais ça ne devrait quand même pas arriver et ça ne devrait pas bloquer la finalisation. Je regarde plutôt du côté des autres logs dont le fail du prevote et la chaîne principale disparue. Je sèche un peu, là. Une journée passée dessus et pas beaucoup de résultat.
Tous les containers sont sur le fuseau UTC. Les hôtes varient en fonction de leur configuration. Donc pas de soucis de date entre les containers je pense.
La vérité est ailleurs…
un petit sudo ntpdate 0.pool.ntp.org sur la machine fautive nan ?
J’ai trouvé comment utiliser OnlineClient dans subxt avec le dernier bloc :
async fn new_client(url: &str) -> (Client, Hash, BlockNumber) {
let client = subxt::backend::rpc::RpcClient::from_insecure_url(url).await.unwrap();
let backend = subxt::backend::legacy::LegacyBackend::builder().build(client);
let best_block = backend.stream_best_block_headers().await.unwrap().next().await.unwrap().unwrap();
let (genesis_hash, runtime_version, metadata) = futures::future::join3(
backend.genesis_hash(),
backend.current_runtime_version(),
backend.legacy_metadata(best_block.1.hash()),
)
.await;
(Client::from_backend_with(genesis_hash.unwrap(), runtime_version.unwrap(), metadata.unwrap(), std::sync::Arc::new(backend)).unwrap(), best_block.1.hash(), best_block.0.number)
}
J’ai posé la question sur le stackexchange (grandpa - Could not cast prevote: previously known block 0x_ has disappeared - Substrate and Polkadot Stack Exchange), mais j’aimerais bien savoir combien d’autres forgerons n’ont pas pu envoyer leur prévote. Je pourrais l’avoir via l’API RPC de GRANDPA, mais nous avons oublié de l’intégrer dans Duniter (cf #250). Donc si les @smiths-GDev peuvent me donner leurs logs autour du dernier bloc finalisé, ça pourrait me donner une indication en attendant.
Est-ce que ceci conviendrait ?
2024-07-12 19:37:00 ✨ Imported #2208390 (0x85e0…1a0a)
2024-07-12 19:37:02 💤 Idle (17 peers), best: #2208390 (0x85e0…1a0a), finalized #2208388 (0x8ab5…262b), ⬇ 24.0kiB/s ⬆ 11.6kiB/s
2024-07-12 19:37:06 🧙 [distance oracle] More than one Babe owner key: oracle cannot work
2024-07-12 19:37:06 ✨ Imported #2208391 (0xc371…9ff3)
2024-07-12 19:37:07 💤 Idle (18 peers), best: #2208391 (0xc371…9ff3), finalized #2208388 (0x8ab5…262b), ⬇ 28.0kiB/s ⬆ 12.6kiB/s
2024-07-12 19:37:08 ✨ Imported #2208389 (0x28d5…1ceb)
2024-07-12 19:37:08 💔 Verification failed for block 0xfbc21460653c3c89597c3df10ce9d8d5aded3a6eecfb40d8d3a77e1a2cf601b4 received from (12D3KooWAikpy6szmM7QW5QYEFqjiiWYJ3AXLU448htzFLqam2Qr): "Header 0xfbc21460653
c3c89597c3df10ce9d8d5aded3a6eecfb40d8d3a77e1a2cf601b4 rejected: too far in the future"
2024-07-12 19:37:08 ♻️ Reorg on #2208391,0xc371…9ff3 to #2208390,0xc51c…8f1a, common ancestor #2208388,0x8ab5…262b
2024-07-12 19:37:08 ✨ Imported #2208390 (0xc51c…8f1a)
2024-07-12 19:37:09 Encountered error finding best chain containing 0xc5aa6d4d5929c8bd22af44f51db17bb5121e248d5eb7e1482f92c90ee5f2c625: couldn't find target block: Chain lookup failed: Requested a finality targe
t using a base 0xc5aa6d4d5929c8bd22af44f51db17bb5121e248d5eb7e1482f92c90ee5f2c625 not in the best chain 0xc51c605ee2f0b94656361fb16a6db71898c2351a292869f7e3d7cd4bf8da8f1a
2024-07-12 19:37:09 Could not cast prevote: previously known block 0xc5aa6d4d5929c8bd22af44f51db17bb5121e248d5eb7e1482f92c90ee5f2c625 has disappeared
Je vois bien la même chose. Je pense que le bug a empêché tous les nœuds forgeron d’envoyer leur prévote grandpa, bloquant la finalisation. Il me reste à remonter à l’origine de ce bug.
Le souci que j’ai indiqué coté squid (syncro de l’indexer très très lente) n’a l’air d’être lente qu’a partir du dernier bloc finalisé, donc avec une peu de chance il se résolvera tout seul en résolvant ce problème de finalisation.
Est-ce que la finalisation est possible s’il y a des nœuds qui n’ont plus les blocs à finaliser ? Peut-être qu’il faudrait déconnecter tous les nœuds non-archive pour permettre aux archives d’avoir un consensus ? Je n’ai aucune idée de comment fonctionne la finalisation.
J’ai moi aussi ce message qui arrive toutes les quelques minutes. Ça correspond à un pair dont le certificat est invalide ? Y a-t-il moyen de l’identifier ?
C’est parce que squid utilise des layers postgres pour les blocs non finalisés qui sont susceptibles d’être annulés. Ça permet de gérer les rollback très facilement.
Non, je pense que c’est d’ailleurs ça le problème : le bloc pour lequel ont voté les forgerons a été mis à la poubelle trop tôt, ce qui les a empêché de voter. Mais une investigation plus poussée est nécessaire…
Les nœuds archive ne participent pas au consensus. Les forgerons ne sont généralement pas configurés comme archive, ça ne leur sert pas. Je ne pense pas qu’en resynchronisant un forgeron en mode archive puisse lui permettre de voter rétrospectivement pour le bloc qu’il n’avait pas à l’époque. Il faudrait trouver un moyen de forcer le vote sur des blocs récents, mais ça n’a pas l’air facile à faire.
Le pairs n’ont pas de certificat, c’est lié à rustls, donc plus probablement à la télémétrie. Je pense que c’est décorrélé.
J’arrête mon nœud pour quelque temps aujourd’hui pour voir si ça débloque la situation, pour obtenir cette finalisation tant attendue 
Je ne pense pas que ça puisse résoudre quoi que ce soit, il n’y aura pas de nouvelle session de vote grandpa, et les blocs oubliés ne seront pas récupérés. Je suis en vacances donc je vais pas pouvoir chercher davantage. J’aimerais que elois puisse nous aider sur ce genre de cas, et sinon on rebootera, mais ce serait dommage parce qu’on louperait une occasion de comprendre ce qui peut mal se passer.
Probablement lié à cela : Finalisation stopped : Encountered error finding best chain · Issue #3487 · paritytech/polkadot-sdk · GitHub, qui a été corrigé la semaine dernière.
Ok, c’est une explication suffisante, donc je propose d’appeler noteStalled en sudo pour l’instant en attendant de publier une nouvelle version de Duniter qui intègre le fix grandpa: handle error from SelectChain::finality_target by andresilva · Pull Request #5153 · paritytech/polkadot-sdk · GitHub. Ça évitera d’avoir trop longtemps une blockchain sans finalisation, ce qui s’est révélé gênant pour plusieurs raisons.
Ça a finalisé 
A post was split to a new topic: LegacyBackend subxt
