Cardano-db-sync: Bucle infinito de pánico / retroceso (NewEpochFailure)

¿Es esta mainnet? ¿Está actualizando de una versión del software a otra?

~ La parte NewEpochFailure del mensaje de error sugiere que la versión db-sync es incompatible con la versión node . ~

La versión 6.0.x de db-sync es compatible con 1.21.x del nodo.

sí, mainnet, construí una nueva base de datos y ahora está funcionando con la misma versión, así que no estoy seguro de qué sucedió

Cerrando esto.

Acabo de hacer clic en esto en el servidor cardano-graphql CI, sin ningún cambio de interés, como actualizaciones de versión. Conectando a la red principal con esta configuración .

[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\"}"]

~ Después de conversar con Rhys en Slack, sospecho que en su caso db-sync tuvo problemas con más de 1000 bloques antes de este error y lo que está viendo es el resultado de reiniciar y rotar los registros. ~

El problema ocurre en el traspaso de la época.

Los que @rhyslbw y @mmahut capturaron vomitaron en el mismo último bloque aplicado, hash 5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987 . Es muy poco probable que sea una coincidencia.

Es muy probable que ese bloque sea el primer bloque de una nueva época.

@rhyslbw ¿cuál es el hash de git de la versión db-sync que estás usando?

El que @mmahut estaba usando en el # 404 fue el compromiso https://github.com/input-output-hk/cardano-db-sync/commit/6187081a7ea66954c86094578bd37e01bca8aaec que falta el compromiso https://github.com/input-output- hk / cardano-db-sync / commit / afe68e08cf5f8b3b1b6690e411670908bc0f5942 que contiene cambios en la configuración del estado del libro mayor. Este problema se trata de que muere en el código relacionado con el estado del libro mayor, pero ese cambio no debería hacer una diferencia en mainnnet. La etiqueta 6.0.0 está después de la segunda confirmación.

Este es un ENORME dolor en el cuello para depurar sin una solución para https://github.com/input-output-hk/cardano-db-sync/issues/256 .

@erikd Estoy usando la etiqueta de lanzamiento commit 3e68f3011bb156b9b799ccf056f9a73281479f9c

Hicimos un montón de trabajo tratando de recrear este problema, pero no es determinista. Actualmente estoy ejecutando una versión de este código que debería detectar mejor cualquier error (y abortar inmediatamente). Espero que exista la posibilidad de activar esto nuevamente en el próximo límite de época, lo que sucederá en aproximadamente 14 horas a partir de ahora.

10 nodos, todos ellos fallaron con este error específico. Los estados son:

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

y usando git rev 6187081a7ea66954c86094578bd37e01bca8aaec (que es un par de confirmaciones detrás de la etiqueta 6.0.0 ).

La hipótesis actual es que el estado del libro mayor se corrompe en algún momento y que la corrupción solo se nota en el límite de la época.

Bucle infinito 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 de 3 instancias arrojaron el error NewEpochFailue .
revisión de 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

Se implementaron las instantáneas de la instancia no afectada.

El hecho de que el mismo archivo de estado del libro mayor, por ejemplo, 13996756.lstate tenga tres hash diferentes, es un poco inesperado.

Si la causa es un estado del libro mayor corrupto, probablemente este y el # 405 sean el mismo problema

@SebastienGllmt Sí, es posible, pero ni siquiera he tenido la oportunidad de mirar el # 405 todavía.

2 de cada 4 instancias derribadas
Sumas de comprobación MD5 de una instancia anómala:

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

(la otra instancia que falla tiene diferentes hashes)

Instancia saludable:

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

Intenté resincronizar 10 instancias diferentes en el compromiso bcd82d0a3eada57fdf7cc71670a46c9b3b80464f (ya que necesito la función de metadatos).

2 de cada 10 tenían una versión dañada de los archivos de estado del libro mayor (diferente del resto). Las sumas correctas son:

/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

También he notado una inconsistencia en los archivos. 14040345.lstate faltaba en la mitad de las instancias, pero estas instancias tenían 14040553.lstate lugar.

Para su información, el mismo problema nuevamente en la transición de época 230 ...

Ok, sé qué está causando el problema. Arreglar esto es relativamente simple. La solución no requerirá una resincronización de la base de datos a menos que el estado del libro mayor ya esté dañado (lo cual será detectado por la versión fija del software).

El problema es:

• Hay dos versiones de una función para aplicar un bloque a un estado de libro mayor; uno lento que realiza comprobaciones completas y uno rápido que realiza menos comprobaciones.
• Dado que db-sync está obteniendo bloques que ya han sido validados por el nodo, parecía sensato usar la versión rápida.
• Me habían dicho que las comprobaciones en la versión rápida incluían comprobar que el hash anterior del bloque coincide con el valor del hash principal en el estado del libro mayor, pero esta comprobación de hash no se estaba realizando.
• El protocolo ocasionalmente permite que más de un líder de ranura acuñe un bloque para una ranura específica, y los bloques que producen tendrán diferentes valores hash (es decir, el bloque incluye datos específicos del líder de ranura).
• Como estoy usando la versión rápida y mi código se revierte a una ranura especificada, es posible que vuelva al número de ranura correcto, pero al bloque incorrecto (es decir, el número de ranura es correcto, pero el hash incorrecto y, por lo tanto, el bloque incorrecto).
• Cuando ahora avanza, la falta de verificación de hash significa que el problema no se detecta hasta el comienzo de la siguiente época.

@erikd ¿Es posible hacer que esta sea una configuración para alternar entre verificación completa y verificación rápida? Preferiría ejecutar todo en modo "seguro" y utilizar recursos adicionales para asegurarme de que se mantenga activo.

@CyberCyclone Una vez que se comprueba el hash, no hay nada más que pueda salir mal con una probabilidad mayor que la posibilidad de una colisión de hash de 256 bits. Se debería haber comprobado el hash. Pensé que lo estaban revisando. Una vez comprobado, no hay razón para realizar más comprobaciones.

¡Genial, genial para escuchar! La forma en que estaba redactado sonaba como si estuvieran sucediendo muchas más cosas. Pero sí, las colisiones de hash no son motivo de preocupación.

Como estoy usando la versión rápida y mi código se revierte a una ranura especificada, es posible que vuelva al número de ranura correcto, pero al bloque incorrecto (es decir, el número de ranura es correcto, pero el hash incorrecto y, por lo tanto, el bloque incorrecto).

_No debería ser posible que retroceda al número de ranura correcto, sino al bloque incorrecto_.

La sincronización de la cadena ordena retroceder a un punto específico de la cadena (el punto es una ranura + hash), pero se garantiza que este punto existe en la cadena del consumidor. Sí, es muy sensato verificarlo, pero si esta verificación fallara, eso indica un error lógico en alguna parte.

Así que creo que esto necesitará más investigación antes de que podamos llamarlo arreglado. Agregar una aserción debería detectar el problema mucho más rápidamente en el punto donde ocurre, en lugar de mucho más tarde en el límite de la época. Por supuesto, agregar una afirmación no es una solución en sí misma.

No debería ser posible que retroceda al número de ranura correcto, sino al bloque incorrecto.

Es posible si la reversión solo verifica el número de ranura pero no el hash.

El registro ahora ha producido esto:

[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. 

lo cual es un poco extraño. Reiniciarlo da como resultado:
''
[db-sync- node: Info : 34] [2020-11-19 09: 06: 15.54 UTC] La sugerencia de la base de datos está en la ranura 8092720, bloque 389107
[db-sync- node: Info : 39] [2020-11-19 09: 06: 15.54 UTC] Ejecutando hilo de base de datos
[db-sync- node: Info : 42] [2020-11-19 09: 06: 15.55 UTC] getHistoryInterpreter: adquirido
[db-sync- node: Info : 39] [2020-11-19 09: 06: 15.55 UTC] Volviendo a la ranura 8092720,
hash e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05
[db-sync- node: Info : 39] [2020-11-19 09: 06: 15.56 UTC] Eliminando ranuras numeradas: []
`` ``
Necesito verificar el código para esto.

Tengo una solución temporal para esto. La solución proviene de mi rama de depuración de trabajo en progreso, pero no se ha probado, sometido a control de calidad ni publicado por completo.

Si alguien está ejecutando la versión 6.0.0 y está preocupado por el traspaso de la época en ~ 12 horas, hay una rama erikd/tmp-fix-6.0.x (confirma 3a6e7199c1f2) con la solución. La solución alternativa detecta que algo va por mal camino, entra en pánico, la ejecución se vuelve a intentar en un nivel superior y luego db-sync continúa.

No hay cambios en la base de datos relacionados con 6.0.0 por lo que no se requiere resincronización.

Sin embargo, ejecutar esta versión puede detectar un estado del libro mayor ya dañado (ni siquiera estoy seguro de cómo se vería), en cuyo caso se requerirá una resincronización.

Después de agregar un montón de código de depuración y luego esperar a que se active el problema.

Resulta que este problema es una condición de carrera. De los registros:

[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

Básicamente lo que sucede es:

• El bloque llega a través de la sincronización en cadena y se pone en la cola.
• Llega el comando de reversión y la reversión en el estado del libro mayor se realiza de inmediato.
• El bloque se lee desde el otro extremo de la cola y se aplica al estado del libro mayor.
• Llega un nuevo bloque, ponlo en la cola y cuando llega al otro extremo los hashes no coinciden porque ya se aplicó un bloque extra incorrecto.

La solución es mover el código al estado del libro mayor de reversión desde el extremo de escritura de la cola hasta el extremo de lectura.

Se corrigió en el maestro en https://github.com/input-output-hk/cardano-db-sync/pull/413 .

También habrá 6.0.1 lanzamiento de