J’étais en train de travailler sur la ǦTest quand je suis tombé sur le cas suivant : des certifications dont la date d’expiration était passée mais qui n’avaient pas encore expiré. J’aimerais comprendre où est le problème pour savoir si on peut l’ignorer sans problème.
j’utilise dex pour lire la base de données, comme indiqué dans py-g1-migrator, j’ai ajouté quelques exports sur la branche hugo-dev
mon export a eu lieu au bloc 640233 avec un medianTime de 1688284294 (2023-07-02 T 07:51:34)
je lance ./main.py 1688284294 de py-g1-migrator sur ma branche hugo-gtest pour simuler un lancement de gtest au moment où a lieu l’export
Parmi ces 11 certifications restantes, seules 2 ont une date d’expiration postérieure au dernier bloc, les 9 autres sont censées avoir déjà expiré.
La question est donc : pourquoi reste-t-il des certifications actives alors que leur date d’expiration est passée (depuis plus de 7 heures) ?
La conséquence est que le parsing du genesis ĞTest n’est pas content. Il fait un check sur Jovivant qui est censé être membre (member: true) et trouve uniquement 2 certifications sur 5 minimum attendues :
Je veux bien des informations supplémentaires pour essayer (modestement) d’aider sur le sujet, si c’est dans le code python qu’il y a un souci…
A quel endroit de la chaîne ETL (extract, transform, load) de migration, ou du workflow de migration si on préfère, les 9 certifications expirées apparaissent non expirées ?
Quelle application fait le parsing du genesis de Gtest et pourquoi/où voit-elle Jovivant comme étant membre ? Alors qu’il ne lui reste manifestement (dans certs.json) que 2 certifications valides.
Y a -t-il déjà des tests d’intégrité des données dans Duniter (pré export dex) et on cherche le bug dans dex, ou bien il serait intéressant que j’implémente un équivalent de dex en Python avec Plyvel, pour analyser/exporter les index levelDB et vérifier leur cohérence ?
Effectivement, j’avais oublié que je l’avais remplacé par member: false pour pouvoir booter la gdev, et effectivement au moment de l’export il l’était.
Je ne sais pas s’il y a des tests d’intégrité dans Duniter v1, je ne sais pas si ça vaut le coup d’implémenter un autre outil pour lire la db. Je le signalais juste ici au cas où quelqu’un rencontre un problème similaire pour que ce soit un minimum documenté.
Bon alors comme cela avait l’air trivial, j’ai fait un script pour lire l’index des identités avec Python et vérifier sur mon serveur Duniter V1 au bloc 642590 environ, que l’UID Jovivant n’est pas membre :
SI dex le présente toujours comme membre, et que ni mon script, ni wotwizard ne le voit membre, alors il y a peut-être un bug dans dex.(et par extension dans le workflow de migration…).
Pour les curieux du Python :
#!/usr/bin/env python
import plyvel
import json
# open copy of leveldb folder, copy made from a running Duniter server
db = plyvel.DB('/home/vit/level_iindex',)
for key, json_string in db:
value = json.loads(json_string)[0]
if value["uid"] == "Jovivant":
print(value)
Évidemment si tu regardes après, il n’est plus membre. Le problème était au bloc de l’export. Dans d’autres blocs il y aura peut-être d’autres problèmes, mais je ne sais pas encore lesquels.
Export wallets data in progress...
Export certs data in progress...
Export identities data in progress...
Export membership data in progress...
Export blocs dates data in progress...
Export UD value in progress...
Starting python script to generate genesis data
Generate ĞTest genesis with up-to-date Ğ1 data
get ĞTest parameters...
dump ĞTest parameters...
parse identities...
⚠️ initial monetary mass 7,281,486,307 does not equal wallet sum 7,281,461,465
money on the wallets: 7,281,376,601
money from ignored sources: 84,864
missing money (added to treasury): 24,842
parse certification...
⚠️ lumi → DCat cert expired between export and start
add simple wallets...
Done
Copying genesis data to bootstrap server
gtest_genesis.json
Il y a une seule certification qui semble avoir expiré entre le moment de l’export et le moment de l’écriture du genesis (lumi → DCat). Mais cela n’explique pas pourquoi Jizo et Moonvaudeurs n’ont que 4 certifications sur 5.
Je trouve que le workflow est difficile à déboguer car trois logiciels sont impliqués dans les transformations de données dans deux langages différents.
L’idéal serait de simplifier ce workflow, en faisant, selon que l’on veuille plus de Rust ou plus de Python :
Rust : intégrer le code de génération de genesis.json de py-g1-migrator dans dex (nécessite un bon dev Rust).
Python : intégrer le code d’extraction des index V1 de dex dans py-g1-migrator (assez trivial avec la lib plyvel, qui est très rapide, et peu de logique dans l’extraction il me semble).
Par rapport aux incohérences, elles semblent être dans la base leveldb. Changer la manière de lire cette base ne changera rien aux incohérences. La raison est plus probablement interne à Duniter et il faut juste décider ce qu’on en fait. Probablement désactiver le statut membre des personnes ayant moins que cinq certifications.
Mais si tu veux ajouter l’export leveldb avec plyvel dans py-g1-migrator, pourquoi pas. Poka avait fait avec l’existant et du bash comme d’habitude, et ça me parait très bien pour un programme qui ne va servir qu’une fois.
Effectivement si l’incohérence des données vient de la base leveldb elle-même, alors ce travail est inutile pour le script de migration de @poka qui fonctionne bien.
Je vais essayer de détecter des incohérences dans la base leveldb avec plyvel, si ce n’est pas trop de travail. Cela peut éventuellement permettre d’améliorer Duniter V1 en attendant la migration.
Suite à la visio d’hier, pour l’implémentation de l’import leveldb 1.8 en python, sur quelle branche veux-tu que je me base ? Je vois que trois personnes ont des branches.
J’ai ouvert un ticket sur lequel on peut continuer à discuter.
J’ai fait le ménage de mes branches, tu peux partir sur master. Il y a un détail sur la date de génération du DU qui a été changé côté Duniter-v2s et qu’il faudra gérer dans py-g1-migrator, mais c’est vraiment un détail, donc pas de problème
