Duniter v2s et l’indexeur ne démarrent pas avec la valeur du DU de la Ğ1

Networks ĞTest
, , , ,
16

Alors, faisons le point.

Suite à ce bug que tu relèves, j’ai tiré les fils.
Il y a déjà un premier problème qui n’a rien à voir avec ça: Quand j’ai lancé cette gtest, je me suis basé sur master pour créer la branche network, évidemment, quoi d’autre ?

Mais étant donné que jusqu’a présent, les branches de network ne sont pas mergés sur master, tous les commits qu’avait fait @elois pour lancer gtest #1 ne se retrouve pas dans ce réseau :scream:

Je viens donc de relire tout ces commits, en fait il n’y avait pas grand chose mais quand même quelques ajustements mineurs, dont certain que j’ai dû reproduire du coup sans quoi Duniter crashait avec le runtime gtest, je ne comprenait pas pourquoi (je pense à l’ajout du protocoleId par exemple).

Mais après relecture, rien dans ses commit n’explique ce comportement, le UdReevalPeriod est correctement set dans les paramètres du runtime gtest:

pub const UdReevalPeriod: Moment = 15_778_800_000; // 1/2 year

Non le problème est ailleurs, et je viens de le comprendre. @Moul a bien fait de déplacer le sujet ici, car c’est lié au paramètre first_ud_reeval que j’ai set dans le yaml gtest

En lisant le code qui interprête cette valeur, en fait il s’attend à un timestamp … au format millisecondes !
Hors je l’ai mis au format secondes…

Du coup ce qu’il se passe:

  • Actuellement la date de première réévaluation du DU est paramétré au … 21 janvier 1970 :partying_face:
  • Tous les jours au moment de la création du DU, le runtime check si il est nécessaire de rééavluer le DU en vérifiant cette date.
  • Comme la condition if moment >= next_reeval est toujours vraie, il réévalue le DU
  • Il ajoute UdReevalPeriod (6 mois) à la date de prochaine réévaluation, passant donc au 21 Juillet 1970, puis le lendemain au 21 Janvier 1971, ect …
  • Le retard sera rattrapé au bout de 110 jours, soit le 30 janvier 2026. oklm.

Conclusion:

C’est ma faute MAIS:

  • @cgeek un argument de plus pour merger les branches network sur master une fois le réseau déployé :slight_smile: (même si ça n’a rien à voir avec la cause du bug en l’occurence).
  • Rajouter un check côté Duniter pour que cette date ne puisse pas être paramétré dans le passé, et que cette erreur ne soit tout bonnement pas possible.
  • Là on peut faire un runtime upgrade pour rajouter 3 zero à ce timestamp, mais entre temps le DU aura déjà été réévalué plusieurs fois
  • Je viens de pousser un fix de cette date au bon format dans le yaml gtest sur la branche network 1100 pour les prochains reboot (à merger du coup).

Autres conclusions:

  • Toujours avoir des relectures du @technical-committee lors du déploiement de nouveaux réseaux :slight_smile:
  • Personne ne moniteur le réseau, il aura fallu attendre 10 jours que @Maaltir s’en rende compte via Gecko.

ping @cgeek @HugoTrentesaux @tuxmain @technical-committee, on en profite pour s’entrainer aux runtime upgrade et tant pi pour les réévaluations déjà encaissés ?

7 Likes