La version 1.7.21 de Duniter, utilisée pour faire tourner WotWizard, rejette obstinément le bloc 434742-00000006B17D15638D67C33F829C406BB3942CF578F8726DE4195BEFD9C2617D, malgré plusieurs essais infructueux de synchronisation. Du coup, WotWizard est bloqué depuis mercredi soir (23 juin).
Quelqu’un aurait-il une idée pour débloquer la situation ? @elois @cgeek
Hypothèse que je n’ai pas le temps de vérifier: peut-être, que du point de vue de duniter 1.7.21, ElenaMavida ne respecte pas la règle de distance, à cause d’un problème d’arrondi.
Si c’est ça il suffit d’augmenter la valeur du param xpercent pour Duniter 1.7.21.
Sinon j’en profite pour te poser une question qui me trotte depuis quelque temps @gerard94 : je n’ai pas vraiment compris pourquoi wotwizard ne fonctionne pas avec Duniter 1.8. Il n’ y a eu aucun changement dans la base de donnée entre la 1.7 et la 1.8 donc ça ne peut pas être un problème de base de donnée.
C’est une bonne idée. Mais, au bloc 434740, ElenaMavida était à au plus 5 pas de 92.58% des membres référents. Ce n’est pas ça.
Duniter 1.7 crée une version SQLite de la base de données, si le paramètre “wotwizard” de conf.json est à true, que WotWizard utilise. Je n’ai jamais pu avoir une description de la bdd leveldb. Si tu peux me la fournir, en attendant GVA, cela résoudrait le problème.
Ok bah je sais pas et n’aurait pas le temps d’investiguer avant la semaine prochaine
L’été dernier je m’en suis créé une moi-même en passant au peigne fin le code typescript lié. J’ai pu décrire un schéma complet de la db leveldb en Rust ici: dbs/src/databases/bc_v1.rs · master · nodes / rust / duniter-core · GitLab
Les types clés et valeur étant défini dans les dossiers dbs/src/keys et dbs/src/values 
Je me souviens avoir utilisé cette doc, qui parle de SQLite mais c’est encore comme ça, sauf que les colonnes sont plus ou moins les champs d’un dictionnaire JSON.
Oui, merci. C’est la doc que j’ai utilisé pour écrire WotWizard.
Oui je m’en doute, mais le diable est dans les détails.
Merci, je vais regarder ça de près.
Pourtant, c’est bien sur la règle de distance que le bloc #434742 est refusé par Duniter 1.7.21, sur l’adhésion de ElenaMavida.
J’aurais plus de détails d’ici 23h.
2 Likes
Voici le détail vu par Duniter 1.7.21 concernant ce bloc 434742 pour l’entrée d’ElenaMavida :
nbSuccess = 1456
nbSentries = 1821
nbReached = 2229
isOutdistanced = true
Si l’on fait le rapport nbSuccess / nbSentries, on obtient 79,95%.
C’est vrai que ça ressemble à un problème d’arrondi, mais dans le cas de la synchro je trouve d’autres données curieuses. Je serai preneur de vos avis quant à ces chiffres.
1 Like
Mon hypothèse était donc juste. C’est un problème déjà connu et qui s’est déjà produit par le passé :
@gerard94 tu es obligé de reset data and sync: la sync ne vérifiant pas la règle de distance ça passera, c’est déjà comme ça qu’on a résolu le problème la dernière fois.
En fait on aurait du considéré la migration du module wotb comme un changement de protocole, puisse que le calcul de la règle de distance diffère légèrement dans certain cas (et qu’il est impossible de calculer l’arrondi de la même façon).
Il faut donc considérer que la version 1.7.21 du Duniter n’est plus supportée (ou resync chaque fois que ce cas rare se produit).
1 Like
Je vais peut-être dire une connerie, mais il peut sans doute arrivé que la règle soit OK lors d’un premier calcul, puis KO avec le même calcul quelque minutes plus tard.
Cas ou quelques nouveau référents apparaissent à plus de 5 pas, ou que quelques certifs sur des chemins critiques arrivent à échéances. Pour quelqu’un juste à la limite cela peut-être fatal.
C’est prévu ça dans le protocole ?
Oui, le temps est celui de la blockchain donc le cas est 100% reproductible et ne dépend pas de l’heure extérieure (de la machine).
Le problème est ailleurs.
Il y a d’une part le problème d’arrondi différent entre Duniter 1.7 et 1.8, mais peut-être aussi un problème de définition de toile. Notamment ce qui me surprend c’est la réponse de @gerard94 qui indique une couverture de 92.58% pour ElenaMavida, plutôt que les 79.95% que m’indique Duniter 1.7.
Un soucis que j’ai pu voir : en faisant une synchronisation jusqu’au bloc 434745 (histoire de ne pas finir la sync sur le bloc problématique), à cette ligne qui vérifie la distance (v1.7.21), la variable current contient le bloc 434745 plutôt que 434741 (on est en train d’ajouter le bloc 434742 !), ce qui est effectivement un bug.
Mais a priori seule la synchro est concernée, c’est la façon dont y sont ajoutés les blocs. Je n’ai pas encore pu voir si ce bug avait un impact sur wotb.
2 Likes
Et pourtant, g1monit, au bloc 434741 lui donne 92.59% (au fait, @elois, g1monit est lui aussi coincé sur ce bloc). À moins que nos deux implémentations de l’algorithme soient fausses, il y a peut-être un problème dans celle de Duniter.
Oui, ça marche, je n’avais pas pensé à effacer préalablement les données. Merci.
g1-monit n’a pas sa propre implémentation, il utilise Duniter pour calculer la distance. Aucune implémentation du calcul de distance n’est en cause, c’est un bug ailleurs qui fourni des données invalides en entrée, apparemment lié à la synchro.
1 Like
Oui, cela paraît logique.