Le fork n’a pas pu être résolus car GerardSiegle devait être exclu car n’ayant que quatre certifications. Le rollback était bloqué à cause de ce problème. Problème causé par le fait qu’il soit entré avec quatre certifications. Là, ça nous dépasse, à cgeek de trouver la raison de ce bug.
Pour les problèmes de synchronisation je sais pas. Il faut ouvrir un ticket avec les logs d’erreur.
Je regarde, mais clairement il y a un bug derrière car l’état n’est pas cohérent selon qu’on reçoit le bloc la 1ère fois où qu’on l’interprète dans le cadre d’une résolution de fork.
Pour le coup c’est bien ce bug là qui est derrière le fork.
Je vais bien entendu révéler le bug dès que je l’aurais débusqué, puis verrouiller le comportement avec un test automatisé qui solutionnera à jamais ce problème.
Duniter peut paraître « fragile » à certains égards, mais il faut savoir que la partie fonctionnelle du programme (= le respect du protocole) est balisée par 700 tests automatisés. C’est la seule et unique raison qui fait que la Ğ1 tient autant la route malgré l’absence de développeurs depuis 2 ans.
Je voudrais préciser quelque chose : À aucun moment je ne doute du fait que chacun fait de son mieux pour que tout fonctionne et soit le plus solide et résilient possible. Et je sais qu’on ne pourra jamais éviter tous les bugs. Donc, c’est important, je ne te remets pas en cause. (Et j’espère que ça n’a pas été commpris comme tel ! )
Ce que je me rends compte, c’est qu’il manque d’autres personnes capables de se pencher sur le code de duniter (le programme). Mais je pense que tu es parfaitement conscient du problème.
Un de mes objectif cette année est de monter en compétences sur tout ça mais n’ayant pas touché vraiment du code depuis longtemps, je pars de loin.
Et bien mauvaise nouvelle : impossible de resync le noeud g1.duniter.org. Il reste bloqué sur le block 285387. J’éteins le noeud en attendant, pour éviter que les utilisateurs envoient leurs document sur un noeud désynchro.
As-tu eu le temps d’essayer plusieurs fois ? J’ai du faire pas mal d’essais pour que ça finisse par passer… Finalement j’ai pu synchroniser depuis le nœud duniter.moul.re.
@cgeek, je suppose que tu es au courant, mais au cas où, j’ai bien l’impression que Remuniter aussi est resté coincé sur le bloc #285383-000004E92CD3.
Enfin… c’est ce qu’affiche le site https://remuniter.cgeek.fr/#/
J’ai fait des petits scripts qui relancent automatiquement la synchro en cas d’échec, car avec mon raspi je tombe souvent sur ce cas-là. À télécharger là : Jean-Yves / scripts-for-duniter · GitLab
Si je ne me trompe pas, Remuniter se connecte sur g1.duniter.org qui est actuellement bloqué, comme @Inso le signale un peu plus haut. C’est donc “normal” (ou en tout cas identifié).
Quand les synchros plantent, est-ce possible que ça soit parce que “le réseau de nœuds” galère ou est surchargé ? Je me demande juste si on risque pas de faire pire en essayant tous de se synchroniser en boucle ?
@Moul, qu’appelles-tu un nœud « spécialisé » ? Il y a un truc de particulier sur ce nœud hormis le fait qu’il y ait un module remuniter associé ? (Ou bien c’est ce que tu entends par spécialisé ?)
Je fais la synchro initiale de Remuniter dessus oui, mais après Remuniter vit sa vie avec le reste du réseau. Non là, Remuniter était simplement bloqué comme d’autres nœuds (dont le mien).
Je ne comprends pas. Que ce soit mon serveur ( http://g1.duniter.inso.ovh/blockchain/current ) ou le serveur nordstrom ou le serveur g1, impossible de réussir la synchro. Elle va au bout mais à chaque fois le noeud reste désynchro).