Bug de synchro sur Ğ1-Test

Networks Ğ1-Test
1

Suite du sujet Besoin d'endpoint BMA pour réparer le réseau g1-test.

Je constate bien un problème de synchro au réseau de test, mais sous plusieurs formes :

  1. en mode --memory --cautious, je tombe sur une erreur au bloc#95417
  2. en mode --memory, je tombe sur une erreur au bloc#140000 (un peu avant le bloc courant, en fait)
  3. en mode --cautious seulement, je n’ai pas d’erreur, mais la synchro est très lente
  4. sans option (synchro classique), j’ai une erreur ruleToBeKickedArePresent déjà repérée par Inso, mais pas de façon systématique :confused: sauf si je précise de faire la synchro pour s’arrêter au bloc #95500, là le bug se répète.

Pour 4), j’ai une piste sérieuse, mais j’ai encore besoin de creuser le sujet. Le symptôme “synchro qui bug” est lié à un mauvais calcul de l’index d’adhésions, mais je vérifie que j’ai bien identifié le pourquoi.

Pour 3), je refais des tests pour valider que malgré tout, la synchro bloc après bloc fonctionne. Mais ça prend vraiment beaucoup de temps ! Pourtant comme celle-ci est censée refléter au mieux le mode « nominal » des nœuds. Pour l’instant sur Ğ1-Test, la synchro se passe bien même au-delà du bloc#95500, ce qui est encourageant.

Mais c’est à cause de cette lenteur que je voulais utiliser le mode --memory, plus rapide. Sauf que celui-ci bug aussi, à mon avis pour une autre raison liée au mode mémmoire.

En conclusion

La synchro qui bug n’est qu’un symptôme d’un soucis plus profond, qui risque d’éclater au 1er anniversaire de la Ğ1. Ce soucis concerne probablement tous les nœuds, v1.5.x comme v1.6.x.

Mais dans l’hypothèse où la full-synchro lente passe, alors on aurait déjà une solution de repli pour les adhésions qui vont expirer début Mars car alors l’index des adhésions semble correctement calculé.

Bref je reviens vers vous dès que je déniche plus d’infos :slight_smile:

3 Likes
2

Bon j’avance : déjà je vois d’où vient le côté aléatoire de l’erreur remontée par @Inso (celle qui remonte ruleToBeKickedArePresent). En fait cette erreur intervient durant les 100 derniers blocs de la synchro, puisque ces derniers sont ajoutés pas à pas. C’est la même erreur que je rencontre en mode --memory --cautious, sauf que je bute dès le bloc 95417 vu que je fais du contrôle à chaque bloc depuis le début de la blockchain.

Le bug se produit quand un membre est indiqué « exclu » dans le bloc, alors que Duniter ne trouve aucune raison valable. Dans ce cas il remonte ruleToBeKickedArePresent, qui signifie aussi bien “ceux à exclure doivent se trouver dans ce champ” que “ceux qui n’ont pas à être dans ce champs ne doivent pas l’être”. Dans le bug remonté, c’est le 2ème cas qui se présente : en effet @Inso a buté sur le bloc 133839, or à ce moment là il y avait justement plein d’exclusions : https://g1-test.cgeek.fr/blockchain/with/excluded :

131980,
134008,
134377,
134582,
134620,
137831

Étant donné que le bloc 133839 n’est pas dans cette liste, je suppose qu’il y a même eu un fork d’une manière ou d’une autre. Mais aussi, le bloc 95417 contient bien un exclu. Je bute dessus moi-même.

Voilà donc une première avancée. Je continue demain :slight_smile:

2 Likes
3

Elle t’a été utile ma bdd ? :slight_smile:

4

Oui ! Très bon réflexe.

1 Like
5

Pour info, je pense avoir trouvé le bug : il se produit pour les membres ayant été exclu par défaut de renouvellement puis s’étant renouvelés pour redevenir membre et se font une nouvelle fois exclure.

Dans ce cas, le champ m_index.expired_on devrait être réinitialisé lors du renouvellement, notamment pour que la règle BR_G26 fonctionne, or il ne l’était pas :

// Join back
pushMindex(index, {
  index: constants.M_INDEX,
  op: constants.IDX_UPDATE,
  pub: ms.issuer,
  created_on: [ms.number, ms.fpr].join('-'),
  written_on: [block.number, block.hash].join('-'),
  writtenOn: block.number,
  age: 0,
  unchainables: 0,
  type: 'JOIN',
  expires_on: conf.msValidity,
  expired_on: null, // <------- Devrait être valorisé à `0`, pas `null` !
  revokes_on: conf.msValidity * constants.REVOCATION_FACTOR,
  revocation: null,
  chainable_on: block.medianTime + conf.msPeriod,
  revoked_on: null,
  leaving: null
})

Or vu que le membre déjà exclu une fois n’a pas son champ expired_on remis à 0 convenablement, la règle d’exclusion BR_G93 - Membership expiry ne s’applique pas correctement pour la 2ème exclusion (et pour toutes les exclusions suivantes en fait) :

If MS.expired_on == null OR MS.expired_on == 0, add a new LOCAL_MINDEX entry:

MINDEX (
op = ‘UPDATE’
pub = MS.pub
written_on = BLOCKSTAMP
expired_on = HEAD.medianTime
)

Et donc quand Duniter voit passer un bloc qui exclu le membre, il ne comprend pas et refuse l’exclusion.

Concernant le bug relevé par Inso

Par conséquent, comme la BR_G93 n’est pas correctement appliquée : il manque aussi des exclusions pour ceux s’étant déjà fait exclure :confused:

Conclusion : la blockchain Ğ1-Test est invalide depuis le block#133839 :roll_eyes:

6 Likes
6

Il y a quand même une bonne nouvelle : la chaîne Ğ1 n’a pour l’instant aucun problème. Mais si l’on ne se met pas à jour, l’embrouille va commencer dès le 8 Mars 2018 ! :grinning:

5 Likes
7

Bon voilà, j’ai produit la Merge Request #1252. Plus qu’à tester les livrables, mais rien de transcendant.

2 Likes
8

On se synchronise sur qui du coup pour ceux qui veulent tester la release ? Avec le bloc invalide, il faut revert / reset data quand un noeud est déja sur la chaine ?

9

Je vais m’occuper de créer un nœud sur le bon point de fork, puis vous pourrez vous synchroniser dessus. Je suis sur le coup, je vous tiens au courant dans l’heure.

Mais il faut d’abord que je génère la release :slight_smile:

2 Likes
10

Je me suis embrouillé et j’ai intégré un commit qui fait échouer les tests. Pas de release avant encore une heure …

2 Likes
11

C’est bon, livrables 1.6.20 disponibles.

J’ai synchronisé mon nœud qui s’est arrêté comme prévu au bloc posant soucis (#133839). Vous pouvez vous synchroniser sur lui : g1-test.cgeek.fr 443.

À noter que le retard est désormais de 17 jours, donc la difficulté va inévitablement chuter. Donc je ne fais pas d’annonce publique pour cette version de test pour le moment, 2 ou 3 personnes suffiront pour rejoindre la date courante.

cc @inso @elois @nanocryk @vit @jytou

12

Je lance la release raspberry… mais je ne pourrai pas la livrer avant un moment…

13

Synchronisé et démarré avec succès :

./bin/duniter sync g1-test.cgeek.fr 443 --nointeractive --nopeers
14

Si tu veux, mais de toute façon on doit d’abord remonter la blockchain.

15

Tu es sûr ? Car pour l’instant ton nœud ne se connecte pas au mien via WS2P.

16

C’est bon :slight_smile:

J’ai joué un sync onlypeers et je me suis connecté :

2018-02-25T16:41:27+01:00 - info: >> Server starting...
2018-02-25T16:41:27+01:00 - info: NodeJS version: v8.9.4
2018-02-25T16:41:27+01:00 - info: Node version: 1.6.20
2018-02-25T16:41:27+01:00 - info: Node pubkey: 2RbXrLkmtgWMcis8NWhPvM7BAGT4xLK5mFRkHiYi2Vc7
2018-02-25T16:41:27+01:00 - info: WS2P server 2RbXrLkmtgWMcis8NWhPvM7BAGT4xLK5mFRkHiYi2Vc7 listening on 37.187.192.109:7777
2018-02-25T16:41:27+01:00 - info: Duniter server listening on http://127.0.0.1:8999
2018-02-25T16:41:27+01:00 - info: >> Server ready!
2018-02-25T16:41:27+01:00 - info: WS2P: init: bundle of peers 1/3
2018-02-25T16:41:27+01:00 - info: Sibling endpoints:
2018-02-25T16:41:27+01:00 - info: BMA access: gtest.duniter.inso.ovh:80
2018-02-25T16:41:27+01:00 - info: ✔ PEER 2RbXrLkm
2018-02-25T16:41:27+01:00 - info: Next peering signal in 4 min
2018-02-25T16:41:27+01:00 - warn: Too high difficulty: waiting for other members to write next block
2018-02-25T16:41:27+01:00 - error: WS2P >>> >>> WS ERROR: INCORRECT_PUBKEY_FOR_REMOTE
2018-02-25T16:41:27+01:00 - info: WS2P: connected to peer 3dnbnYY9 using `WS2P 88.174.120.187 20900`!
17

OK dans ce cas ne touche plus à ton nœud, je m’occupe du reste :slight_smile:

18

@Inso c’est bon, nous sommes appairés !

edit : par contre il calcule ton nœud en ce moment ?

edit 2 : ah si c’est bon, c’est juste très lent …

19

Ah tu veux dire qu’il vaut mieux avoir des nœuds qui carburent ?

20

Non mais simplement qu’on sera assez de 2 nœuds, et on ne tourne pas sous ARM :slight_smile:

1 Like