Duniter 1.7.14 : résout les forks de la Ğ1 des dernières semaines


#41

J’ai contourner ça. cf https://git.duniter.org/nodes/typescript/duniter/merge_requests/1276#note_14409

La CI n’est pas configurée pour les dépôts forks du projet.


#42

Je trouve qu’avec ces deux correctifs (la 1.7.14 et 1.7.15) on a essuyé pas mal de plâtres de la migration 1.6 −> 1.7.


#43

Je n’ai pas oublié non plus, mais je manque aussi de temps cette semaine, et le week-end va être encore pire en terme de temps. :stuck_out_tongue:


#44

J’ai attaché le Runner habituel de Duniter au fork de bpresles afin que la CI passe sur sa Merge Request. Les tests sont passés, nickel.

@bpresles tu as fait un super boulot, non seulement tu as corrigé le bug mais surtout tu as verrouillé le comportement avec un test unitaire. Je te remercie pour cette contribution et pour le coup, je te fais un don personnel de 100DU pour ce travail exemplaire. Merci à toi.


#45

@cgeek Merci :relaxed:


#46

Si ton offre tient toujours, je te laisse faire :slight_smile:


#47

Ok, j’attendais. Je m’en occupe.


#48

Je viens de committer la modif pour rendre possible les releases arm (et potentiellement windows). Je ne l’avais pas fait et du coup je me retrouve à nouveau dans le pétrin pour faire la release. :stuck_out_tongue:


#49

J’ai relancé les tests. Ils échouent des fois sur un test de la PoW.
Tu as un autre problème ?


#50

Merci, cela dit ça n’est pas normal que tu aies eu ce bug.

Voici ma version de TypeScript quand en dev:

$ yarn tsc -v
yarn run v1.7.0
$ tsc -v
Version 3.1.6

Donc, TypeScript 3.1.6. Mon hypothèse : tu as une version différente.


#51

Cette nuit (vers 3h00 du matin), il y a eu de nouveaux forks, visiblement résolus depuis. Mais la blockchain a été ralentie de plusieurs heures à cause de cela. D’ailleurs celle-ci a encore environ 3h de retard actuellement.

C’est dommage que l’on ai pas encore d’outil de suivi, ce serait vraiment super de pouvoir visualiser graphiquement ce qui s’est passé. En tout cas Remuniter m’indique qu’il a dans sa BDD 74 forks potentiels à suivre. Du coup je le resynchronise, il semble un peu perdu.

La cause est peut-être que des nœuds migrés en 1.7.14 n’ont pas été resynchronisés (comme indiqué dans le message de livraison ci-dessus), ce qui expliquerait que des soft-forks continuent de se produire. Si c’est un autre problème, tant que nous n’aurons pas d’outils de diagnostics performants, ça risque d’être compliqué d’en comprendre l’origine :confused:


#52

Je me suis demandé si implémenter un client WS2P en Python dans Duniterpy était une perte de temps ou pas. J’ai laissé tombé pour des implémentations plus prioritaires.

Mais j’ai l’impression que cela peut-être utile pour faire le genre d’outils dont tu parles à des fins d’analyses statistiques, pour le debug et la maintenance de Duniter.

De plus je voudrais faire un helper scannant le réseau pour détecter la chaîne majoritaire (pour que tous les clients Python puissent être réellement p2p comme Sakia) et je me demande si utiliser WS2P ne serait pas plus efficace que GVA.

Alors, un client WS2P en Python dans Duniterpy ? Utile ou inutile ?


#53

Cela permettrait de donner un accès “temps réel” à la vie de la blockchain, notamment via les trames WS2P HEAD, mais aussi la réception des blocs et autres données qui transitent via cette API.

Maintenant il est aussi possible d’exploiter BMA pour récupérer ces mêmes trames (via /network/ws2p/heads), mais pas en mode push. Donc il faut puller régulièrement.

L’accès WS2P te permet d’accumuler des données en mode push, donc d’être notifié de tous les événements qui se propagent (ainsi, tu seras notifié du fait qu’un nœud, même planqué derrière sa box en WS2P Privé, change d’état). C’est en effet une voie intéressante pour faire du monitoring.


#54

Juste un petit mot pour dire que mon raspi n’avait jamais aussi bien tourné qu’avec cette version. Il ne “traine” plus et parvient à calculer, lentement mais sûrement, et je ne suis plus obligé de refaire une synchro tous les 3 jours. Je sais pas ce que tu as changé, @cgeek, mais c’est beaucoup plus stable pour mon petit noeud (!).


#55

J’ai un problème depuis la 1.7, lorsque je mets le PC en veille, duniter ne synchronise pas à la sortie de la veille mais calcule quand même. N’est-ce pas générateur de fork ?
Je le ferme et le démarre et il se resynchronise. La prochaine fois je tenterai de faire un STOP/START pour voir si ça fonctionne aussi.


#56

Ça sera un embranchement que pour lui, car il a un retard majeur par rapport aux autres nœuds du réseau.
Du coup, cet embranchement devrait être rapidement résolut et il rejoindra la branche majoritaire.


#57

Ok, à la fin de mon test j’ouvrirai une issue sur l’absence de synchro à la sortie du mode veille.


#58

Petite question sur les 6h30 de retard de la blockchain : va-t-il être rattrapé ?


#59

Le sujet est traité dans ce post Bug à l’ajout d’une certification d’un non membre dans le bloc à calculer : v1.7.16

Si les forgerons se mettent à jour, ça sera rattrapé plus rapidement. Sinon, oui, l’algorithme du protocole fait que ça sera rattrapé tôt ou tard. Le niveau de difficulté commune de preuve de travail a déjà bien chuté.


#60

Question de néophyte : faisant tourner un nœud Windows, est-il utile ou nuisible que je le fasse tourner dans sa dernière version disponible, à savoir la 1.7.11, ou bien vaut-il mieux que je renonce à faire tourner ce nœud en attendant une nouvelle version Windows ?

Par ailleurs j’ai, selon les nœuds sur lesquels mon Cesium se cale, des différences d’état “membre” ou non et du “nombre de certifications” reçus. Cela vous intéresse-t-il de connaitre ces différences et les nœuds correspondants ?