Cardano-db-sync: Loop infinito de pânico / reversão (NewEpochFailure)

Isso é mainnet? Você está atualizando de uma versão do software para outra?

~ A parte NewEpochFailure da mensagem de erro sugere que a versão db-sync é incompatível com a versão node . ~

A versão 6.0.x de db-sync é compatível com 1.21.x do nó.

sim, mainnet, eu construí um novo banco de dados e ele está funcionando agora com a mesma versão, então não tenho certeza do que aconteceu

Fechando isso.

Acabei de acessar isso no servidor cardano-graphql CI, sem nenhuma alteração de interesse, como atualizações de versão. Conectando-se à rede principal com esta configuração .

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

~ Depois de conversar com Rhys no Slack, suspeito que, no caso dele, db-sync teve problemas em mais de 1000 blocos antes desse erro e o que ele está vendo é o resultado de reiniciar e girar os logs. ~

O problema acontece no rollover de época.

Os que @rhyslbw e @mmahut pegaram ambos vomitando no mesmo último bloco aplicado, hash 5d8ea0d4cf2d4f46cc91aa48e83c029691f836d7200e11e26402f9a2bcb25987 . É muito improvável que seja uma coincidência.

Muito provavelmente esse bloco é o primeiro bloco de uma nova época.

@rhyslbw qual é o hash git da versão db-sync você está usando?

O que @mmahut estava usando em # 404 era commit https://github.com/input-output-hk/cardano-db-sync/commit/6187081a7ea66954c86094578bd37e01bca8aaec que não tem commit https://github.com/input-output- hk / cardano-db-sync / commit / afe68e08cf5f8b3b1b6690e411670908bc0f5942 que contém alterações na configuração do estado do razão. Este problema é sobre ele morrer no código relacionado ao estado do razão, mas essa mudança não deve fazer diferença na mainnnet. A tag 6.0.0 está após o segundo commit.

Depurar sem uma correção para https://github.com/input-output-hk/cardano-db-sync/issues/256 é uma enorme dor de cabeça.

@erikd estou usando a tag de lançamento commit 3e68f3011bb156b9b799ccf056f9a73281479f9c

Fiz um monte de trabalho a tentar recriar este problema, mas não é determinista. No momento, estou executando uma versão deste código que deve detectar melhor qualquer erro (e abortar imediatamente). Espero que haja uma chance de acionar isso novamente no próximo limite de época, o que acontecerá em cerca de 14 horas a partir de agora.

10 nós, todos eles falharam com este bug específico. Os estados são:

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

e usando git rev 6187081a7ea66954c86094578bd37e01bca8aaec (que é um par de commits por trás da tag 6.0.0 ).

A hipótese atual é que o estado do razão fica corrompido em algum ponto e que a corrupção só é percebida no limite da época.

Loop 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 instâncias geraram o erro NewEpochFailue .
revisão 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

Os instantâneos da instância não afetada foram lançados.

O fato de o mesmo arquivo de estado do razão, por exemplo, 13996756.lstate ter três hashes diferentes, é um pouco inesperado.

Se a causa for um estado de razão corrompido, provavelmente este e # 405 são o mesmo problema

@SebastienGllmt Sim, isso é possível, mas eu nem tive a chance de olhar o # 405 ainda.

2 de 4 instâncias eliminadas
Soma de verificação MD5 de uma instância com falha:

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

(a outra instância com falha tem hashes diferentes)

Instância saudável:

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

Tentei ressincronizar 10 instâncias diferentes no commit bcd82d0a3eada57fdf7cc71670a46c9b3b80464f (pois preciso do recurso de metadados).

2 em cada 10 tinham uma versão corrompida dos arquivos de estado do razão (diferente do resto). As somas corretas são:

/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

Também notei uma inconsistência nos arquivos. 14040345.lstate estava faltando em metade das instâncias, mas essas instâncias tinham 14040553.lstate .

Para sua informação, o mesmo problema novamente na transição da época 230 ...

Ok, eu sei o que está causando o problema. Consertar isso é relativamente simples. A correção não exigirá uma ressincronização do banco de dados, a menos que o estado do razão já esteja corrompido (o que será detectado pela versão corrigida do software).

O problema é:

• Existem duas versões de uma função para aplicar um bloco a um estado de razão; um lento que faz uma verificação completa e um rápido que faz menos verificações.
• Como db-sync está recebendo blocos que já foram validados pelo nó, pareceu sensato usar a versão rápida.
• Disseram-me que as verificações na versão rápida incluíam verificar se o hash anterior do bloco corresponde ao valor do hash principal no estado do razão, mas essa verificação de hash não estava sendo feita.
• O protocolo ocasionalmente permite que mais de um líder de slot crie um bloco para um slot específico, e os blocos que eles produzem terão hashes diferentes (ou seja, o bloco inclui dados específicos para o líder de slot).
• Como estou usando a versão rápida e meu código retorna para um slot especificado, é possível que ele retorne para o número de slot correto, mas para o bloco errado (ou seja, número de slot correto, mas hash errado e, portanto, bloco errado).
• Quando agora rola para frente, a falta de verificação de hash significa que o problema não foi detectado até o início da próxima época.

@erikd É possível alternar a configuração entre a verificação completa e a verificação rápida? Eu prefiro executar tudo no modo "seguro" e usar recursos extras para garantir que ele permaneça ativo.

@CyberCyclone Depois que o hash é verificado, não há mais nada que possa dar errado com probabilidade maior do que a chance de uma colisão de hash de 256 bits. O hash deveria ter sido verificado. Eu pensei que estava sendo verificado. Depois de verificado, não há razão para fazer mais verificações.

Incrível, ótimo ouvir! A forma como foi redigido parecia que havia muito mais coisas acontecendo. Mas sim, as colisões de hash não são nada com que se preocupar.

Como estou usando a versão rápida e meu código retorna para um slot especificado, é possível que ele retorne para o número de slot correto, mas para o bloco errado (ou seja, número de slot correto, mas hash errado e, portanto, bloco errado).

_Não deve ser possível retroceder para o número de slot correto, mas para o bloco errado_.

A sincronização da cadeia instrui para reverter para um ponto especificado na cadeia (ponto sendo um slot + hash), mas esse ponto tem a garantia de existir na cadeia do consumidor. Sim, é muito sensato verificar, mas se essa verificação falhar, isso indica um bug de lógica em algum lugar.

Portanto, acho que isso vai precisar de mais investigação antes de podermos chamá-lo de consertado. Adicionar uma asserção deve detectar o problema muito mais rapidamente no ponto em que ocorre, em vez de muito mais tarde no limite da época. Adicionar uma asserção não é em si uma correção, é claro.

Não deveria ser possível voltar para o número de slot correto, mas para o bloco errado.

É possível se a reversão verificar apenas o número do slot, mas não o hash.

O registro agora produziu isto:

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

o que é um pouco estranho. Reiniciá-lo resulta em:
`` `
[db-sync- node: Info : 34] [2020-11-19 09: 06: 15.54 UTC] A ponta do banco de dados está no slot 8092720, bloco 389107
[db-sync- node: Info : 39] [2020-11-19 09: 06: 15.54 UTC] Executando thread de banco de dados
[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] Revertendo para o slot 8092720,
hash e1e78605937bb8cfc842d1ee7280b92fa9fce813c26fa66a88eaca74d7af9f05
[db-sync- node: Info : 39] [2020-11-19 09: 06: 15.56 UTC] Excluindo slots numerados: []
`` ``
Precisa verificar o código para isso.

Eu tenho uma solução temporária para corrigir isso. A solução vem do meu branch de depuração de trabalho em andamento, mas não foi totalmente testado, QAed ou lançado.

Se alguém está executando a versão 6.0.0 e está preocupado com o rollover da época ocorrendo em ~ 12 horas, há um branch erikd/tmp-fix-6.0.x (commit 3a6e7199c1f2) com a solução alternativa. A solução alternativa detecta algo extraviado, entra em pânico, a execução é repetida em um nível superior e, em seguida, o db-sync continua.

Não há alterações no banco de dados em relação a 6.0.0 portanto, não é necessário sincronizar novamente.

No entanto, a execução desta versão pode detectar um estado de razão já corrompido (nem tenho certeza de como seria), caso em que será necessária uma ressincronização.

Depois de adicionar um monte de código de depuração e, em seguida, esperar que o problema seja acionado.

Acontece que esse problema é uma condição de corrida. Dos 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

Basicamente, o que acontece é:

• O bloco chega via chainsync e é colocado na fila.
• O comando de reversão chega e a reversão no estado do razão é feita imediatamente.
• O bloco é lido na outra extremidade da fila e aplicado ao estado do razão.
• Novo bloco chega, é colocado na fila e quando chega na outra extremidade os hashes não combinam porque um bloco extra errado já foi aplicado.

A correção é mover o código para reverter o estado do razão da extremidade de gravação da fila para a extremidade de leitura.

Corrigido no mestre em https://github.com/input-output-hk/cardano-db-sync/pull/413 .

Haverá também 6.0.1 release corrigindo isso.