Ces clés changes très régulièrement, parfois elles repassent en solde normal, parfois d’autre passe en négative, jamais plus de 3 ou 4 à la fois en général…
Si quelqu’un sait debugguer et corriger ça c’est cool, car si cela impact GVA, peut être que Dex aussi si ils manipules la même DB.
Pour le moment pour palier ce soucis dans mon parsing genesis, je remplace les soldes négatifs par 0.
En sommant toutes les transactions (listées avec jaklis) et en ajoutant environ un an de DU (cette identité a l’air membre depuis novembre 2021) j’obtiens quelque chose vers -50 G1. Silkaj donne 725.31 Ğ1. Pourtant l’historique a l’air complet, et d’autres comptes sont exacts sur jaklis.
python jaklis.py -n https://g1.librelois.fr/gva history -p AjQDUMjbQbDX9CWsfFDf97fdNXiyqnYyGQd8GfgUXBwe -n 1000
C’est peut-être une erreur dans le compte du DU. Peux-tu vérifier s’il y a corrélation entre le fait d’être (ou d’avoir été) membre et le solde négatif ? (ou encore mieux mais demande plus de temps et de travail, comparer avec le vrai solde)
Si je compare mon compte F8DoNzvUb11EftKqsodEnuJBbJiPh5rt16z9dADCS2cK sur césium et sur cette page de stat
Je trouve 3618,69 sur cesium et 3629.2 sur la page de stat.
Soit une différence de 10.51 étrangement, c’est la valeur d’un DU du mois précédent, mais je ne vois vraiment pas le rapport.
Je ne sais pas si cela peu aider au diagnostique.
Le compte AjQDUMjbQbDX9CWsfFDf97fdNXiyqnYyGQd8GfgUXBwe de maga65 affiche
685,90 dans césium et -453.59 dans les stats est-ce que le fait qu’il y a une transaction récente influe ?
Le compte4AmVZgYKPU9nhNqUz9fnv5UVZssFZ7T1HwMbwXZrZuUN de celineR affiche 367,24 dans cesium et -421.01 dans les stats
Ca m’étonnerais que ce soit une coïncidence, on remarque qu’en effet seul des membres semblent affectés par ces soucis de soldes.
Je rappel aussi pour aider au diag, que ces comptes changent très souvent, si vous regardez demain il y a des chances pour certains comptes à soldes négatifs aient changés, certains repassés en positifs, d’autres arrivés en négatifs…
On remarque déjà que le solde négatif de AjQDUMjbQbDX9CWsfFDf97fdNXiyqnYyGQd8GfgUXBwe a changé entre mon message d’hier et aujourd’hui (ainsi que les 3 autres comptes négatifs en fait si vous regardez mon screenshot)
Alors si on cherche des coïncidences étranges, il s’avère que j’ai perdu mon status de membre pendant quelques heures entre le 7 et 8 septembre 2022. Ce qui n’aurait du avoir aucune incidence puisque j’ai renouvelé mon adhésion vers 10h du matin donc avant la création du DU. J’avoue je n’ai pas vérifié mon solde à ce moment là, mais c’est peut-être là que césium ou les stats se mélangent les pinceaux…
Ca me semble en effet une piste très intéressante.
Comme si il manquait des index de DU dans la DB utilisé par GVA, peut être dû a des sorties/re-rentrés par exemple.
Si tel est le cas, alors ce n’est pas un soucis qui concerne GVA, mais directement sa DB, donc probablement Dex, mais si quelqu’un peut vérifier que le pbm est le même avec Dex ce serait pas mal.
Le bug est peut être plus difficile a corriger que prévus, mais je n’en sais strictement rien.
Si c’est trop profond tant pi on se passera de GVA et Dex, on utilisera uniquement BMA/wot-wizard/Pod Cs+ pour les données finals.
Étant donné que la plupart des comptes sont corrects et que les (maigres) tests de l’indexeur GVA passent (j’en ai ajouté un pour une transaction et un DU dans un même bloc, ça marche), ça va être compliqué.
Quelques pistes pour GVA :
un bug dans l’application du DU ou des transactions
un bug dans le revert d’un bloc (si c’est le cas, seule la résolution d’un fork devrait créer des erreurs, donc un nœud fraîchement synchronisé n’aurait pas le problème. Comme au moins 2 nœuds ont le même problème, ça semble peu probable.)
un bug du suivi de l’état de membre
une erreur dans un bloc, tolérée par Duniter mais pas pas gva-indexer, qui causerait une erreur non fatale
une concentration de rayons cosmiques sur les nœuds GVA
GVA me donne 1 DU(t-1) soit 10,51 G1 de plus que BMA ! Donc l’anomalie va dans les deux sens.
Le compte AjQDUMjbQbDX9CWsfFDf97fdNXiyqnYyGQd8GfgUXBwe:HoS a 1189.49 G1 de plus selon BMA que selon GVA. En tout cas il n’y a aucune grosse transaction qui serait différente dans les historiques. Et le compte a fait une transaction depuis ce matin, les soldes ont évolué d’autant, la différence n’a pas bougé.
Quels 2 noeuds ? Le seul noeud GVA qui tourne actuellement est https://g1.librelois.fr/gva
Ca ne pourrait pas être un problème isolé à ce noeud, sur une mauvaise sync ?
Sachant que le problème a été détecté dès le classement forbes a été refacto avec la requête wallets de GVA, donc ya 1 an a peu prêt
J’ai dit 2 en supposant que tu utilisais https://duniter-g1.p2p.legal/gva/gva qui est le nœud par défaut de jaklis (chez moi, du moins), chez moi il faisait une erreur donc j’ai pris https://g1.librelois.fr/gva.
Il s’agit du seul bug bloquant pour la mise en production de clients basés sur GVA. Les espagnoles sont en train de lancer 2 clients sur GVA: Le Ğ1 super bot, un bot Telegram, déjà fonctionnel je l’ai testé, développé par kapis, qui utilise jaklis, et Ginkgo, un client flutter multiplateforme qui utilise la lib durt.
Ce bug semble venir de l’absence de DU comptabilisés sur certain wallets, je n’ai pas encore pris le temps d’isoler pourquoi exactement avec suffisamment de tests croisés.
Je propose un bug bounty en Ğ1 pour celui ou celle qui extirpera la punaise derrière ces soldes, en piochant dans la caisse des dev Duniter. Ouai je lance ça comme ça lol
Qu’en pensez-vous ? 100DU ? J’ai l’impression que la caisse des dev est assez rempli pour ce genre de bounty non ?
Je pense qu’il ne devrait plus être question de GVA. Investir dans une solution temporaire, c’est pas tellement stratégique. N’est-il pas possible d’obtenir le solde via BMA et RPC/indexer ?
Le bot pourrait utiliser Silkaj au lieu de jaklis pour récupérer le solde.
Ginkgo devrait viser la v2. Sinon, viser la v1 qui est moins stratégique, en calculant le solde avec les requêtes BMA. Je pense que c’est moins d’efforts que de corriger GVA. L’algorithme pour obtenir le solde existe dans Silkaj et Césium.
Non il n’y a aucun intérêt de dev Ginkgo en v2, autant contribuer à Ğecko directement dans ce cas là.
Oui mais je te laisse comparer le temps de réponse entre BMA et GVA, donc entre Silkaj et Jaklis.
C’est le jour et la nuit.
Au passage, j’avais déjà fait un bot Telegram pour la Ğ1, foncitonnel, et multi chat (telegram, rocketchat axiom, FB messenger et bien d’autres) en 2019, qui utilisait Silkaj oui:
Je l’ai montré à Kapis, et il a décidé de partir sur des techno plus récentes pour son bot (byebye Hubot en nodejs remplacé par un bot maintenu et en python) et jaklis au lieux de Silkaj, plutôt que de continuer mon bot.
Oui c’est la stratégie que je proposais depuis quelques mois, encore faut il développer un plugin de l’indexer qui index la blockchain v1 à partir de BMA. C’est pour moi la meilleur option en effet, mais kapis et vjrj ne semblent pas partir dans cette direction.
Je n’ai pas encore pris le temps de dev ce plugin en TS, j’ai d’autres priorités, mais c’est vrai qu’on devrait faire ça je pense, et ainsi partir de suite sur la stack v2s pour l’ensemble de l’écosystème v1 en lecture, dès maintenant.
Tout dépend du “temporaire”, écoutez, moi j’étais dans l’optique de migrer en Juin car selon moi, Duniter v2s est suffisament prêt comparé à duniter v1 pour migrer en juin si on se concentre sur les réglages nécessaires. Hugo n’est pas du tout dans cette démarche, à peu prêt opposé à la mienne, et vise plutôt 2 à 3 ans, donc disons qu’on est pas sur les même temporalités.
Au vue de ces délais, on prévois même d’organisrt un hackaton Cesium v1 avec @aya pour régler des bugs intolérables laissés en prod depuis bien trop longtemps, ainsi que brancher GVA dessus pour certaines requêtes.
Moi je commence à en avoir un peu marre de ne toujours pas pouvoir mettre Gecko en prod, dans l’attente infinie de Duniter v2s, donc je soutiens toutes les démarches qui vont dans le sens d’améliorer l’écosystème technique v1.
Pour moi tout dépends de la difficulté à débusquer ce bug, j’ai commencé à regarder le code du dépôt GVA hier, ça m’a pas l’air bien compliqué, il suffit de comprendre l’ensemble du circuit et de mettre le doigt sur l’endroit où ça pourrait coincer, avec un test.
L’idée n’est pas d’y passer 1 mois, mais peut être qu’en 1 journée ce serait réglé par quelqu’un déjà à l’aise avec Rust. Ou du moins pour comprendre la cause précise du soucis.
Mais je maintiens que oui, je suis d’accords avec toi, dev un plugin indexer en TS qui index la blockchain v1 à partir de BMA serait plus judicieux. Encore que, si ce bug solde de GVA est résolu, on pourrait utiliser GVA pour indexer la v1 directement, ce serait donc quasiment instantané grâce à la requête wallets, puis la souscription aux nouveaux blocs (vraiment). Alors qu’il faudrait des heures et des heures avec BMA.
GVA fonctionne en prod, nous l’avons suffisamment testé pour le confirmer, seul ce bug reste bloquant.
Je n’ai pas dit ça. Tu as interprété autre chose. Ce n’est pas grave. Je ne serais également pas pour la solution temporaire que tu proposes.
Tu as bien raison, c’est lent d’obtenir le solde d’un compte avec les multiples requêtes à faire sur BMA. Je ne souhaite pas influencer les développements de chacun. Cette solution temporaire est très bien pour un résultat rapide.
Je défendais plutôt les fonds de la caisse Duniter. S’ils devaient être utilisés pour des financements, bug bounty, autre que la rémunération actuelle, il faudrait en discuter ensemble pour savoir quels projets financer dans une réflexion globale du projet technique Duniter/Ğ1.
If helps to debug, what I saw is that the same non member account can have a negative balance in at least one server that is in sync also. What I’m doing is to mark that server as faulty and try in other and works as a workaround.
The screenshot of
showed the server with negative balance in my wallet .
BrgsSYK3xUzDyztGBHmxq69gfNxBfe2UKpxG21oZUBr5 marked with some errors.
I can try to collect more info if you are interested.
Please, feel free to continue this talk in French.
PS: Also the balance is not always the same in different synced gva nodes. This can be easy be tested in g1nkgo opening the balance and pressing the refresh as it retries in different synced nodes.
Ça ne viendrai pas du fait que l’indexation des TX est parfois désactivée, sur certains nœuds ?
Si oui, il manque une fonction pour savoir si le noeud a activé ou non l’option. Je l’ai déjà demandé pour Cesium. Afin de pouvoir sélectionner un noeud aléatoirement.
