Bug fenetre courante dans remuniter, cesium et silkaj

Remuniter et silkaj considèrent que le bloc courant fait parti de la fenêtre courante, or d’après les règles BRG_04 et BR_G18 (entre autre), ce n’est pas le cas :

HEAD.issuersCount = COUNT(UNIQ((HEAD~1..<HEAD~1.issuersFrame>).issuer))
blocksOfIssuer = HEAD~1..<HEAD~1.issuersFrame>[issuer=HEAD.issuer]

Je me suis rendu compte de cet écart en testant une contribution de @ji_emme a Dunitrust qui consiste en l’ajout d’une commande blocks affichant l’équivalent de la commande blocks de silkaj (affichage du nombre de blocs forgés par chaque membre dans la fenêtre courante).

Afin de tester, j’ai comparé les résultats avec ceux affichés par remuniter et silkaj. Et c’est la que j’ai trouvé la différence. J’ai d’abord pensé a un bug coté Dunitrust mais après vérification des spécifications il s’avère que c’est remuniter et silkaj qui ont tord :stuck_out_tongue:

Cesium est également concerné dans le calcul de la difficulté personnalisée des membres (vue réseau en mode expert).

ticket Silkaj: https://git.duniter.org/clients/python/silkaj/issues/243
ticket Cesium: https://git.duniter.org/clients/cesium-grp/cesium/issues/840
ticket Remuniter: https://github.com/duniter/remuniter/issues/17

3 J'aimes

Ça serait pas plus intéressant de faire les choses dans l’autre sens, à savoir considérer le bloc courant dans la fenêtre courante ?

C’est un comportement connu de cgeek, mais qui n’a pas été modifié, car peu prioritaire.

Avoir un protocole cohérent plutôt que demander aux clients d’implémenter un comportement non-cohérent. À moins, que le fait de ne pas inclure le bloc courant dans la fenêtre courante a du sens ? S’agit-il d’une fonctionnalité ?

Réimplémenter de nouveau un protocole est le moment idéal pour remettre à plat le protocole et corriger ses petites imperfections. Luxe que n’avait pas l’auteur du protocole et son implémentation.

1 J'aime

Au fond je comprend tout a fait @Moul mais on ne peut hélas pas procéder ainsi :confused:

Il nous faut d’abord une v1 de Dunitrust en prod qui fasse ses preuves en appliquant le protocole existant a la lettre, et c’est seulement quand cette étape sera passée que nous (les dev de dunitrust) pourront proposer des changements de protocole.

Tant que cette étape n’est pas atteinte c’est Duniter qui sert de référence et tout changement de protocole doit d’abord être implémenté dans Duniter, donc pour le moment je me contente de suivre les changements de Duniter quand il y en a.

Soit les clients s’adaptent à la lettre au protocole existant soit le bug vas traîner encore au moins 2 ans (sauf a ce qu’un développeur de Duniter implémente ce changement de protocole avant).

Et ça ne c’est rien @Moul , il y a beaucoup de comportements “non-cohérents” que je suis obligé d’implémenter dans Dunitrust et qui te ferait bondir (comme reproduire artificiellement les failles de la grammaire de parsing des documents de Duniter), cela est indispensable pour garantir que les utilisateurs de la Ğ1 ne subiront pas de régression.

Enfin, ce qui nous parait “non-cohérent” peut en fait l’être pour des raisons qui nous échappent, c’est pour cela que tout changement de protocole doit faire l’objet d’une proposition formalisée et validée par des pairs :slight_smile:

1 J'aime

Oui, excuse-moi, c’est pas le bon moment pour effectuer des changements de protocoles à l’initiative du projet Dunitrust.

La commande blocks a avant tout pour but de monitorer le réseau, et ne pas afficher le bloc courant c’est mettre à mal cette fonctionnalité.

Suivant l’affichage en mode compact ou non des blocs, ça peut-être fait. En affichage compact, c’est possible de respecter cette règle. Par contre, en affichage non-compact, je souhaite que le bloc courant soit affiché. Peut-être en séparant le bloc courant des blocs de la fenêtre courante (en ajoutant le dernier manquant).

1 J'aime