Cardano-db-sync: Boucle infinie de panique/rollback (NewEpochFailure)

Est-ce le réseau principal ? Passez-vous d'une version du logiciel à une autre ?

~La partie NewEpochFailure du message d'erreur suggère que la version db-sync est incompatible avec la version node .~

La version 6.0.x de db-sync est compatible avec 1.21.x du nœud.

oui, réseau principal, j'ai construit une nouvelle base de données et elle fonctionne maintenant avec la même version, donc je ne sais pas ce qui s'est passé

En fermant ça.

Je viens de frapper ceci sur le serveur CI cardano-graphql , sans aucun changement d'intérêt tel que les mises à jour de version. Connexion au réseau principal avec cette configuration .

[db-sync-node:Error:62741] [2020-11-12 06:02:09.50 UTC] runDBThread: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node:Error:62736] [2020-11-12 06:02:09.50 UTC] ChainSyncWithBlocksPtcl: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node.Subscription:Error:62732] [2020-11-12 06:02:09.50 UTC] [String "Application Exception: LocalAddress {getFilePath = \"/node-ipc/node.socket\"} Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "SubscriptionTrace"]
[db-sync-node.ErrorPolicy:Error:4] [2020-11-12 06:02:09.50 UTC] [String "ErrorPolicyUnhandledApplicationException Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "ErrorPolicyTrace",String "LocalAddress {getFilePath = \"/node-ipc/node.socket\"}"]
[db-sync-node.Handshake:Info:62759] [2020-11-12 06:02:17.54 UTC] [String "Send (ClientAgency TokPropose,MsgProposeVersions (fromList [(NodeToClientV_1,TInt 764824073),(NodeToClientV_2,TInt 764824073),(NodeToClientV_3,TInt 764824073)]))",String "LocalHandshakeTrace",String "ConnectionId {localAddress = LocalAddress {getFilePath = \"\"}, remoteAddress = LocalAddress {getFilePath = \"/ipc/node.socket\"}}"]
[db-sync-node.Handshake:Info:62759] [2020-11-12 06:02:17.54 UTC] [String "Recv (ServerAgency TokConfirm,MsgAcceptVersion NodeToClientV_3 (TInt 764824073))",String "LocalHandshakeTrace",String "ConnectionId {localAddress = LocalAddress {getFilePath = \"\"}, remoteAddress = LocalAddress {getFilePath = \"/ipc/node.socket\"}}"]
[db-sync-node:Info:62763] [2020-11-12 06:02:17.54 UTC] Starting chainSyncClient
[db-sync-node:Info:62763] [2020-11-12 06:02:17.55 UTC] Cardano.Db tip is at slot 13564796, block 4938498
[db-sync-node:Info:62768] [2020-11-12 06:02:17.55 UTC] Running DB thread
[db-sync-node:Info:62768] [2020-11-12 06:02:18.01 UTC] Rolling back to slot 13564796, hash 5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987
[db-sync-node:Info:62768] [2020-11-12 06:02:18.01 UTC] Deleting slots numbered: []
[db-sync-node:Error:62768] [2020-11-12 06:02:19.47 UTC] runDBThread: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node:Error:62763] [2020-11-12 06:02:19.47 UTC] ChainSyncWithBlocksPtcl: Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]
CallStack (from HasCallStack):
  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation
[db-sync-node.Subscription:Error:62759] [2020-11-12 06:02:19.47 UTC] [String "Application Exception: LocalAddress {getFilePath = \"/node-ipc/node.socket\"} Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "SubscriptionTrace"]
[db-sync-node.ErrorPolicy:Error:4] [2020-11-12 06:02:19.47 UTC] [String "ErrorPolicyUnhandledApplicationException Panic! applyHeaderTransition failed: [[NewEpochFailure (EpochFailure (NewPpFailure (UnexpectedDepositPot (Coin 831366000000) (Coin 831368000000))))]]\nCallStack (from HasCallStack):\n  error, called at src/Shelley/Spec/Ledger/API/Validation.hs:92:15 in shelley-spec-ledger-0.1.0.0-3QeazRqhkmeDSfJ73hDh1U:Shelley.Spec.Ledger.API.Validation",String "ErrorPolicyTrace",String "LocalAddress {getFilePath = \"/node-ipc/node.socket\"}"]

~Après avoir discuté avec Rhys sur Slack, je soupçonne que dans son cas db-sync rencontré des problèmes sur plus de 1000 blocs avant cette erreur et ce qu'il voit est le résultat du redémarrage et de la rotation des journaux.~

Le problème se produit au renversement d'époque.

Ceux @rhyslbw et @mmahut ont tous les deux été pris en flagrant délit sur le même dernier bloc appliqué, le hachage 5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987 . Il est très peu probable que ce soit une coïncidence.

Il est fort probable que ce bloc soit le premier bloc d'une nouvelle époque.

@rhyslbw quel est le hachage git de la version db-sync vous utilisez ?

Celui que @mmahut utilisait dans # 404 était le commit https://github.com/input-output-hk/cardano-db-sync/commit/6187081a7ea66954c86094578bd37e01bca8aaec qui manque le commit https://github.com/input-output- hk/cardano-db-sync/commit/afe68e08cf5f8b3b1b6690e411670908bc0f5942 qui contient les modifications apportées à la configuration de l'état du grand livre. Ce problème concerne sa mort dans le code lié à l'état du grand livre, mais ce changement ne devrait pas faire de différence sur le réseau principal. La balise 6.0.0 est après le deuxième commit.

C'est une énorme douleur dans le cou à déboguer sans correctif pour https://github.com/input-output-hk/cardano-db-sync/issues/256 .

@erikd J'utilise la balise release commit 3e68f3011bb156b9b799ccf056f9a73281479f9c

A fait BEAUCOUP de travail pour essayer de recréer ce problème, mais ce n'est pas déterministe. J'exécute actuellement une version de ce code qui devrait mieux détecter les erreurs (et abandonner immédiatement). J'espère qu'il y a une chance de déclencher cela à nouveau sur la prochaine limite d'époque qui se produira dans environ 14 heures à partir de maintenant.

10 nœuds, tous se sont écrasés avec ce bogue spécifique. Les derniers sont :

65bce9e6463a324d612d24588afbdecc  13996555.lstate
77b5e894f8a22cb49605b9bfd474588a  13996568.lstate
12c4be3b0fac587d1b6485284e218404  13996582.lstate
f0b29f6768c836e7283f7033799ce146  13996626.lstate
ba72f63cf8185150c8120f3466756479  13996646.lstate
a2b45038665701084196a238b3beb329  13996669.lstate
7e8cccd8f0f1c3ac519ef7471a998ac1  13996713.lstate
ab304c279c8209e4b21a623b1a6dd80f  13996756.lstate

et en utilisant git rev 6187081a7ea66954c86094578bd37e01bca8aaec (qui est quelques commits derrière la balise 6.0.0 ).

L'hypothèse actuelle est que l'état du grand livre est corrompu à un moment donné et que la corruption n'est remarquée qu'à la limite de l'époque.

Boucle infinie NewEpochFailue

99d3e16a319a20ff689ca9582425ddae  13996555.lstate
8205deb9c2b3ad946a99bc7692d4434e  13996568.lstate
8eeb20d372cf5214db7c8287a052707b  13996582.lstate
7133fb72aa8194efa80e95c3fa4af1fb  13996626.lstate
f7199d4a131c6fd4649a76a51167275f  13996646.lstate
faa8d71771e8cc68703fa4f1f08dfce7  13996669.lstate
f6cbf62dad57439dc126f8b56061a863  13996713.lstate
504ea06cb925868c25c100d7d05d6afd  13996756.lstate

cardano-db-sync-extended 6.0.0 - linux-x86_64 - ghc-8.6
git revision 3e68f3011bb156b9b799ccf056f9a73281479f9c

2 instances sur 3 ont généré l'erreur NewEpochFailue .
révision git 3e68f3011bb156b9b799ccf056f9a73281479f9c

0eb144b880dcb07c8347b560ea77db27  13996555.lstate
6ee65fc1f5d47fbb858e92770e109f0f  13996568.lstate
c526b055c731173bb7a94cbf3144855d  13996582.lstate
932f8a4807537c43332a4b9a91c0c4a7  13996626.lstate
95163e7b5351b04ae5909d221a4ee2e2  13996646.lstate
c584485911b8f246d01e37572b0f4175  13996669.lstate
449a7c5b2669288dfec995867507211a  13996713.lstate
ba8c8f7f1657727c826ca07be4f7d2e2  13996756.lstate

Les instantanés de l'instance non affectée ont été déployés.

Le fait que le même fichier d'état du grand livre, par exemple 13996756.lstate ait trois hachages différents est un peu inattendu.

Si la cause est un état de grand livre corrompu, probablement ceci et # 405 sont le même problème

@SebastienGllmt Oui, c'est possible, mais je n'ai même pas encore eu l'occasion de regarder le # 405.

2 instances sur 4 rejetées
Sommes de contrôle MD5 d'une instance défaillante :

189def79f03972649fdcdcd811def1bb  13996555.lstate
dc6865de6149fdf4879a4659bcf02ef0  13996568.lstate
85bf1965fdadee3ee42c10dfd32e0bdb  13996582.lstate
c452477105dc4041c17d718a32f12056  13996626.lstate
9eb0f1fd0a165a8eff3ec4835f370d6d  13996646.lstate
4d5180ba656234020a71f2d46f1d9d0e  13996669.lstate
521ae28570c1630a18bc721cc4707eaa  13996713.lstate
9a2485e192578c1d3c22059648fba79f  13996756.lstate

(l'autre instance défaillante a des hachages différents)

Instance saine :

98d46070c972d7b4ec564e4053e29eda  14033709.lstate
5c2443fe558a928a86606136337f3648  14033754.lstate
6c180d350ba7becf0f02d698ac160397  14033800.lstate
d655e560b8a43e064b671266795d262c  14033812.lstate
99bfbf88ec497e7e40865c920f8e8e26  14033839.lstate
bec82d94fe348d843389853cd24a3e5b  14033845.lstate
14faba941a24f02b236d784af85f8d32  14033890.lstate
c96d18f7bdadebed8e3b723b4e6691fc  14033936.lstate

J'ai essayé de resynchroniser 10 instances différentes sur commit bcd82d0a3eada57fdf7cc71670a46c9b3b80464f (car j'ai besoin de la fonctionnalité de métadonnées).

2 sur 10 avaient une version corrompue des fichiers d'état du grand livre (différente des autres). Les sommes correctes sont :

/var/lib/csyncdb/14040345.lstate | b1df6bdb2cf6f798d9baf83373a4698f
/var/lib/csyncdb/14040390.lstate | 5694a00b12b47052125178175289ba24
/var/lib/csyncdb/14040394.lstate | b45a5e4b82362def92225a3eec5d1afb
/var/lib/csyncdb/14040412.lstate | 8319589d1b66dffd97f5233c3dcfddd0
/var/lib/csyncdb/14040436.lstate | 9d0fec3f4693bd78f426c34c5aaa5d5d
/var/lib/csyncdb/14040462.lstate | 8afe16d592a57ed5ef79a27adf0803d9
/var/lib/csyncdb/14040481.lstate | bcc2648eb09b0d5503f6397569b33e67
/var/lib/csyncdb/14040527.lstate | 588d787363bfe02cf0fd34ac8f412dd4
/var/lib/csyncdb/14040553.lstate | e1f2f42a1ac49d2ec3a53351d1b267b5

J'ai également remarqué une incohérence dans les fichiers. 14040345.lstate manquait sur la moitié des instances, mais ces instances avaient 14040553.lstate place.

Pour info, même problème encore sur la transition de l'époque 230...

Ok, je sais ce qui cause le problème. La résolution de ce problème est relativement simple. Le correctif ne nécessitera pas de resynchronisation de la base de données à moins que l'état du grand livre ne soit déjà corrompu (ce qui sera détecté par la version corrigée du logiciel).

Le problème est:

• Il existe deux versions d'une fonction pour appliquer un bloc à un état de grand livre ; un lent qui effectue une vérification complète et un rapide qui effectue moins de vérifications.
• Étant donné que db-sync obtient des blocs qui ont déjà été validés par le nœud, il semblait judicieux d'utiliser la version rapide.
• On m'avait dit que les vérifications de la version rapide incluaient la vérification que le hachage précédent du bloc correspondait à la valeur du hachage principal dans l'état du grand livre, mais cette vérification de hachage n'était pas effectuée.
• Le protocole permet occasionnellement à plus d'un slot leader de créer un bloc pour un slot spécifique, et les blocs qu'ils produisent auront des hachages
• Étant donné que j'utilise la version rapide et que mon code revient à un emplacement spécifié, il lui est possible de revenir au bon numéro d'emplacement, mais au mauvais bloc (c'est-à-dire le numéro d'emplacement correct, mais le mauvais hachage et donc le mauvais bloc).
• Lorsqu'il avance maintenant, l'absence de vérification du hachage signifie que le problème n'est détecté qu'au début de l'époque suivante.

@erikd Est-il possible d'en faire une configuration pour basculer entre une vérification complète et une vérification rapide ? Je préférerais tout exécuter en mode "sans échec" et utiliser des ressources supplémentaires pour m'assurer qu'il reste actif.

@CyberCyclone Une fois le hachage vérifié, il n'y a rien d'autre qui puisse mal tourner avec une probabilité supérieure au risque d'une collision de hachage 256 bits. Le hachage aurait dû être vérifié. Je pensais que c'était en cours de vérification. Une fois qu'il est vérifié, il n'y a aucune raison de faire plus de vérification.

Génial, génial à entendre ! La façon dont c'était formulé sonnait comme s'il se passait beaucoup plus de choses. Mais oui, les collisions de hachage ne sont pas de quoi s'inquiéter.

Étant donné que j'utilise la version rapide et que mon code revient à un emplacement spécifié, il lui est possible de revenir au bon numéro d'emplacement, mais au mauvais bloc (c'est-à-dire le numéro d'emplacement correct, mais le mauvais hachage et donc le mauvais bloc).

Il ne devrait _pas être possible de revenir au bon numéro de slot, mais au mauvais bloc_.

La synchronisation de la chaîne demande de revenir à un point spécifié de la chaîne (le point étant un emplacement + un hachage), mais ce point est garanti d'exister sur la chaîne du consommateur. Oui, il est très judicieux de vérifier, mais si cette vérification échoue, cela indique un bogue logique quelque part.

Je pense donc que cela nécessitera plus d'enquête avant de pouvoir dire que c'est corrigé. L'ajout d'une assertion devrait détecter le problème beaucoup plus rapidement au moment où il se produit, plutôt que beaucoup plus tard à la limite de l'époque. L'ajout d'une assertion n'est bien sûr pas en soi une solution.

Il ne devrait pas être possible de revenir au bon numéro d'emplacement, mais au mauvais bloc.

C'est possible si le rollback vérifie uniquement le numéro de slot mais pas le hachage.

La journalisation a maintenant produit ceci :

[db-sync-node:Info:39] [2020-11-19 08:47:21.84 UTC] Rolling back to slot 8092720, 
        hash e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05
[db-sync-node:Info:39] [2020-11-19 08:47:21.84 UTC] Deleting slots numbered: [8092760]
Ledger state hash mismatch. Ledger expects 6f1940937d806865a6e96b25a640deb8c1393852fd3d311dbd648e2bfa89056e
        but block provides e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05. 

ce qui est un peu étrange. Le redémarrer entraîne :
```
[db-sync- node:Info :34] [2020-11-19 09:06:15.54 UTC] L'astuce de la base de données se trouve à l'emplacement 8092720, bloc 389107
[db-sync- node:Info :39] [2020-11-19 09:06:15.54 UTC] Exécution du thread de base de données
[db-sync- node:Info :42] [2020-11-19 09:06:15.55 UTC] getHistoryInterpreter : acquis
[db-sync- node:Info :39] [2020-11-19 09:06:15.55 UTC] Revenir à l'emplacement 8092720,
hachage e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05
[db-sync- node:Info :39] [2020-11-19 09:06:15.56 UTC] Suppression des emplacements numérotés : []
````
Besoin de vérifier le code pour cela.

J'ai un correctif temporaire pour cela. Le contournement provient de ma branche de débogage en cours, mais n'a pas été entièrement testé, QAed ou publié.

Si quelqu'un exécute la version 6.0.0 et s'inquiète que le changement d'époque ait lieu dans environ 12 heures, il existe une branche erikd/tmp-fix-6.0.x (commit 3a6e7199c1f2) avec la solution de contournement. La solution de contournement détecte que quelque chose s'égare, panique, l'exception est réessayée à un niveau supérieur, puis db-sync continue.

Il n'y a aucun changement de base de données par rapport à 6.0.0 donc aucune resynchronisation n'est requise.

Cependant, l'exécution de cette version peut détecter un état de grand livre déjà corrompu (je ne sais même pas à quoi cela ressemblerait), auquel cas une resynchronisation sera nécessaire.

Après avoir ajouté un tas de code de débogage, puis attendu que le problème soit déclenché.

Il s'avère que ce problème est une condition de course. À partir des journaux :

[2020-11-21 08:27:09.90 UTC] insertShelleyBlock: epoch 230, slot 14380936, block 4978632,
    hash f984eead753a149efad752dd58471d0c53c3fcf973d281acf4fdcbc6fda799c7
[2020-11-21 08:27:34.22 UTC] insertShelleyBlock: epoch 230, slot 14380962, block 4978633,
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:36.69 UTC] loadLedgerState: slot 14380962
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:37.15 UTC] insertShelleyBlock: epoch 230, slot 14380964, block 4978634,
    hash 1ef4771244b95d35c59371521d19fc145646f89f28bf7a18c4f6c8d7485da2b3
[2020-11-21 08:27:40.01 UTC] Rolling back to slot 14380962,
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:40.02 UTC] Deleting slots numbered: [14380964]
[2020-11-21 08:27:40.35 UTC] ChainSyncWithBlocksPtcl: FatalError {fatalErrorMessage = "Ledger state hash
    mismatch. Ledger head is slot 14380964 hash
    1ef4771244b95d35c59371521d19fc145646f89f28bf7a18c4f6c8d7485da2b3 but block previous hash is 
    bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a and block current
    hash is 136956bd1c6ce536e3c3bb0cef07b3e380441522317c88274f1455a7b11ca2d5."}
[2020-11-21 08:27:41.35 UTC] Starting chainSyncClient
[2020-11-21 08:27:41.36 UTC] Database tip is at slot 14380962, block 4978633
[2020-11-21 08:27:41.36 UTC] Running DB thread
[2020-11-21 08:27:41.54 UTC] Rolling back to slot 14380962,
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a
[2020-11-21 08:27:41.54 UTC] Deleting slots numbered: []
[2020-11-21 08:27:42.54 UTC] loadLedgerState: slot 14380962
    hash bfe35e62b322d397fa6c5080ccd8294c0d2eaca5695e604df59f27f82292227a

En gros ce qui se passe c'est :

• Le bloc arrive via chainsync et est mis dans la file d'attente.
• La commande d'annulation arrive et l'annulation de l'état du grand livre est effectuée immédiatement.
• Le bloc est lu à l'autre extrémité de la file d'attente et appliqué à l'état du grand livre.
• Un nouveau bloc arrive, mis dans la file d'attente et lorsqu'il arrive à l'autre extrémité, les hachages ne correspondent pas car un bloc supplémentaire erroné a déjà été appliqué.

Le correctif consiste à déplacer le code vers l'état du registre d'annulation de la fin d'écriture de la file d'attente à la fin de lecture.

Corrigé sur le maître dans https://github.com/input-output-hk/cardano-db-sync/pull/413 .

Il y aura également une version 6.0.1 corrigeant cela.