Aide au diagnostic de fork

Support Duniter-v1
1

Comme me l’a signalé @kalimheros, mon nœud Duniter semble bloqué au bloc 600652, et incapable de résoudre son fork, pourtant d’un seul bloc.

https://g1cotis.fr/kz/

bloc précédent ok :

Je pourrais resynchroniser et oublier, mais si c’est l’occasion de découvrir un bug dans Duniter, autant en profiter (je continuerai l’investigation quand j’aurai le temps).

Je rappelle aux gens qui utilisent mon nœud que celui-ci est expérimental et que je ne cherche pas à maximiser le temps de disponibilité (“uptime”). Les services branchés sur ce nœud vont également être impactés (wotwizard trentesaux et datajune).

2 Likes
2

Mon noeud mirroir semble lui aussi bloqué mais sur un autre bloc : 601271. Ça ne semble pas être un problème de fork toutefois, car le hash est le même que pour g1.duniter.org.

La seule différence semble être les champs blockstampTime qui sont à 0 sur mon noeud, et 1676284007 sur g1.duniter.org.

Habituellement un redémarrage du noeud lui permet de raccrocher les wagons. Mais c’est curieux…

2 Likes
3

Je continue le diff :

  • issuer bloc duniter : 8fYS16KxGNaMyr6ZQXY9zVZpPKeSL1JeJ2REsXFrCo75 (JP-Rod)
  • issuer bloc trentesaux : 32jZNQLKYfW9KtCHiaSewR27ZRb6zoncC6JvBVCBW4k1 (fdrubigny)
  • time bloc duniter : 1676098220 (2023-02-11T06:50:20)
  • time bloc trentesaux : 1676099547 (2023-02-11T07:12:27) (~20 min plus tard)

Une transaction diffère car elle ne prend pas les mêmes DU source. Mais comme la transaction est construite côté client, c’est juste une transaction différente qui a été choisie (je n’ai pas vérifié la validité de la transaction).

A priori, seule le temps aurait pu poser un problème, mais le temps median est le même.

Je m’arrête là, mais il y a sûrement un bug derrière, et un bug capable d’arrêter Duniter, mon nœud n’est pas le seul à être arrêté à ce bloc, il y a aussi :

1 Like