Comportement bizarre de Duniter 1.6.11

Depuis ce matin, régulièrement, mon noeud veut admettre comme membre HydenStark1 (pubkey : GFZPHnrwNMoJZiYaUPi8S7qhHxbkJ3TVpHapVRzLLQgj), dont l’identité a déjà été révoquée. Donc il forke, puis rentre dans le rang pour recommencer au bloc suivant.

1 Like

À noter que ce bug ne provient probablement pas de la v1.6.11, mais plutôt que les événements se superposent. Ticket#1190 créé.

1 Like

:thinking:

Comment le vois tu ? dans les log ? Si oui peut tu les partager ?

Je le vois directement dans la table block de la bdd.

3 Likes

@gerard94 merci et merci à @cgeek aussi pour le titre du ticket qui m’a mis sur la voie :slight_smile:

Il y a effectivement un bug semi-critique dans Duniter, et qui n’a rien a voir avec la 1.6, il est présent peut être depuis toujours, au moins depuis la dernière réécriture du module prover.

Et ce bug est bien lié au problème anormal de refus de mes blocs par le réseau.

Explications :
Lorsque duniter prépare le contenu du prochain bloc a écrire (c’est le module prover qui fait çà), il n’exclu pas les clés révoqués, ainsi une clé révoquée mais qui redemande a être membre va être réinscrite dans le bloc, et donc refusée par le réseau…

Je viens de coder un correctif mais je n’ai pas encore pu le tester car ma clé membre est exclu du calcul des blocs, je doit attendre …

1 Like

Merci à toi !

1 Like

Youhou mon correctif fonctionne et passe tout les tests :slight_smile:

https://github.com/duniter/duniter/commit/a86503a9eccb087e23a24ff662b7dfe2b2f399f6

2 Likes

Il mériterait l’écriture de son propre test aussi non ?

1 Like

D’ailleurs ça ne se voit pas ici, mais ces blocs sont marqués comme « fork », ils sont présents dans la BDD comme blocs potentiels (générés par ton propre nœud) mais ne sont jamais acceptés. On voit notamment que ton nœud n’accepte pas ce bloc vu qu’il re-génère plusieurs fois le même bloc (même n°).

Donc ton nœud ne forke pas à proprement parler, mais il patauge pour générer son bloc.

Bon, comme les tests ne sont pas encore très faciles à appréhender et que c’est une partie qui me tient à cœur, j’ai rédigé le test : https://github.com/duniter/duniter/commit/d752c1cdddc8c2e8d851f3c73aac773d2c321887

Le test ne passait pas avant la correction d’Eloïs, puis passe une fois celle-ci appliquée. Pour vous en convaincre, changez la ligne 65 du fichier blockGenerator.ts en ceci :

const wereExcludeds:string[] = []

Ce qui revient à annuler la correction. Alors, le test ne passera plus : on verra Duniter tenter d’inclure une clé révoquée dans le champ joiners du bloc. Puis si l’on remet la correction, le test passe de nouveau, le champ joiners est vide comme attendu.

En fait, c’est le cas où une clé révoquée demande à redevenir membre : HydenStark1 a révoqué son compte et tente de revenir, certainement en cliquant sur « Renouveler mon adhésion » dans un client. Malheureusement c’est trop tard pour ce compte-là, il lui faut en recréer un nouveau.

1 Like

Ça cache probablement un bug dans un client d’ailleurs :slight_smile: si quelqu’un sait qui est HydenStark et quel client il utilise…

Au moins, c’est réconfortant.