Ğ1-test bloquée : bloc généré mais refusé de part sa taille

Networks Ğ1-Test
21

C’est un phénomène que les plus anciens ont déjà observé plusieurs fois après un blocage : ce dernier est interprété comme une difficulté trop élevée, et donc à mesure que Duniter trouve des blocs la difficulté diminue jusqu’à devenir dérisoire et que finalement l’heure soit rattrapée.

L’épisode ne dure généralement pas longtemps, actuellement la difficulté est remontée à 71, vous devriez pouvoir synchroniser sur mon noeud et raccrocher les wagons.

5 Likes
22

J’avais un autre processus qui tournait et qui prenait un peu de mémoire… visiblement trop. Il faut dire que j’ai mis un swap absolument ridicule sur le raspi car les cartes SD n’aiment pas du tout quand ça swappe. Du coup, il faut vraiment ne laisser que Duniter tourner sinon ça coince rapidement.

23

Bon dans la suite de cette aventure :

J’ai des problèmes pour envoyer des transactions sur notre nœud officiel :

Error while publishing transaction: {
  "ucode": 1010,
  "message": "The transactions' sandbox is full. Please retry with another document or retry later."
}

Uniquement g1-test.duniter.org est surbooké ou buggé :

curl g1-test.duniter.org/node/sandboxes
{
(…)
  "transactions": {
    "size": 200,
    "free": -1186
  }
}⏎
1 Like
24

je viens de passer en 1.7.11, je rattrape les blocs manifestement

25

Oui, c’est une protection. Aujourd’hui le seul moyen de contourner ce problème est d’envoyer la transaction sur un autre nœud, ou encore d’attendre que la piscine soit vide (ce qui peut ne jamais arriver si un bot la spam).

D’où l’intérêt d’avoir son propre nœud.

26

Ok, mais c’est pas un bug le fait que le nombre soit négatif ?

27

C’est moi ou ĞTest a un petit problème : une chaîne bloquée sur le bloc 312708 datant d’hier soir (dont le nœud de cgeek… et le mien), une autre chaîne qui semble avancer et est au bloc 313099 (inso, elois, moul, attilax, bbv).

J’ai ça dans les logs :

    2019-01-25T22:48:00+01:00 - error:  Error: ruleDividend
    at Function.checkBlock (/opt/duniter/app/lib/blockchain/DuniterBlockchain.js:88:19)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:160:7)
2019-01-25T22:48:00+01:00 - error:  Error: ruleDividend
    at Function.checkBlock (/opt/duniter/app/lib/blockchain/DuniterBlockchain.js:88:19)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:160:7)

Et ça :

2019-01-25T22:48:19+01:00 - info: Fork resolution: 302 potential block(s) found...
2019-01-25T22:48:20+01:00 - info: Fork resolution: block #312709-000039B6 is known as incorrect. Skipping.
2 Likes
28

On dirait qu’il y a deux chaines parallèles… Super bizarre.

29

pareil, j’ai upgrade mais je me suis retrouvé en avance sur la chaine, j’ai resync sans changement. j’ai ensuite effacé le contenu de la blockchain puis resync et là je suis toujours en avance sur la chaine (et j’apparais en orange sur cesium)

30

Je me suis raccroché aux wagons de la bonne chaîne hier soir, ça tourne !

31

t’as sync sur g1-test.cgeek.fr ou g1-test.duniter.org ?

32

Ni l’un ni l’autre, ils étaient tous les deux sur la mauvaise chaîne :stuck_out_tongue: J’ai synchro sur legacy.g1test.nordstrom.duniter.org

33

Super, j’essaie tout de suite. Comment tu as trouvé le “bon noeud” ? AU pif ?

34

J’ai regardé dans cesium les différents nœuds sur la bonne chaîne et j’ai essayé… certains n’ont pas répondu lors de la sync, mais celui-là répondait. Par contre, je suis en train de faire quelques manips sur mon nœud (joyeusetés de noms DNS pour rediriger vers les bons ports…) donc mieux vaut ne pas se synchro sur lui, là. :stuck_out_tongue:

35

Effectivement il y a deux chaînes maintenant. Conservons-les un temps, afin de comprendre ce qu’il s’est passé.

edit : l’erreur est bien ruleDividend, on peut voir que les nœuds de chaque branche ne sont pas d’accord sur le montant du DU :

2 Likes
36

Je sais pas si c’est lié, mais comme ont en a pas parlé ici, la base est passé de 0 à 1 à partir du bloc 233473.
C’est loin par rapport à cet évènement, mais on sait jamais.

2 Likes
37

La branche portée par g1-test.duniter.org semble avoir un problème. Le même bloc problématique est listé plusieurs fois et les blocs précédents affichent une valeur du DU de l’autre branche :

      309606,
      310198,
      310663,
      311127,
      311602,
      311854,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709,
      312709
    ]
  }
}⏎
38

Non, marche pas non plus. Je me refous sur g-test.duniter.org, on verra bien.

39

Non en effet ce n’est pas lié.

Mais à ce stade je ne sais pas dire laquelle des deux chaînes est la bonne. La seule chose que je peux dire : pour certains nœuds le montant du DU a subi une réévaluation, pour d’autres non. De fait, le montant du DU lorsqu’il est co-produit n’est pas le même.

Ce week-end je n’ai pas la possibilité de faire davantage de recherches, nous aurons donc la réponse la semaine prochaine. Tant pis sur la ĞT doit être réécrite, cette monnaie est faite pour cela.

3 Likes
40

Sur la branche portée par g1-test.duniter.org, j’ai des mauvais retours sur /history/<pubkey> :

jsonschema.exceptions.ValidationError: None is not of type 'number'

Failed validating 'type' in schema['properties']['history']['properties']['sent']['items']['properties']['time']:
    {'type': 'number'}

On instance['history']['sent'][0]['time']:
    None

Sur l’autre branche ça se passe bien.