La monnaie ĞTest a révélé un bug dans le code de Duniter qui l’empêche d’avancer, la monnaie de test est donc bloquée depuis quelques jours.
La monnaie Ğ1 n’est pas impactée immédiatement par ce bug, mais le sera dans environ 20 mois 
pour les nœuds n’ayant pas resynchronisé en version 1.7.18 ou supérieur d’ici là.
Télécharger Duniter 1.7.18 et resynchroniser son nœud 
Bug technique dans le couche d’accès aux données
Les symptômes et investigations ont été décrits dans le sujet dédié aux blocages sur ĞTest.
La cause technique provient du code dédié à l’élagage de la base de données des certifications : en cas de certification (c#0) renouvelée (par c#1), au terme de la validité du renouvellement (c#1) l’élagage ne retirait pas l’entrée concernant la certification initiale (c#0) mais uniquement la dernière (c#1).
Or quand une certification expire, celle-ci est supprimée de l’outil de calcul de distance wotb.
Dès lors, quand une autre certification (c#2) émise par le même compte (ayant émis c#0 et c#1) expirait également, Duniter retrouvait à nouveau la certification initiale (c#0) comme faisant partie des certifications à faire expirer et donc déclenchait à nouveau sa suppression au sein de wotb. Et là, c’est le core dump (accès mémoire illégal). 
Correction et verrouillage par un test
Le correctif a donc consisté a supprimer toutes les entrées plutôt que seulement la dernière. Le test automatisé dédié s’occupe de reproduire le bug, puis de vérifier que tout se passe bien. Pour vous assurer que le test fait bien son boulot, retirez le correctif puis lancez le test :
$ yarn test --grep "Certification expiry"
[...]
2019-05-02T22:01:00+02:00 - trace: removeLink 1 -> 2
Segmentation fault (core dumped)
error Command failed with exit code 139.
Le même test avec le correctif :
$ yarn test --grep "Certification expiry"
[...]
6 passing (1s)
Done in 4.18s.
Commentaires sur ce bug
J’avais précisé à @Moul, dans le sujet où nous investiguions, que trouver l’origine serait très difficile. En effet si vous regardez le code fautif, cela ne saute vraiment pas aux yeux.
Pour en trouver l’origine il nous a fallu une première passe d’investigation, et j’ai moi-même du lancer Duniter en mode debug et passer une synchro avec un point d’arrêt conditionnel pour établir l’état précis des données au moment du bug pour comprendre.
Je pense que si cette partie du code avait été plus claire (il s’agit de la nouvelle couche d’accès aux données, plus rapide que l’ancienne car plus bas niveau, mais donc aussi plus verbeuse à la manipulation) ce bug aurait moins eu de chance de s’y nicher.
Ça tombe bien, il me semble que cette partie pourrait gagner à être mise au propre 
voilà qui pourra nous servir d’exemple explicatif pour les RML13.
Versions Windows et ARM
@jytou, un build stp ? (tu chômes pas cette semaine ! 
)
Bonne soirée à tous.