Closed AskAlexSharov closed 3 months ago
So log 1:
Ok can avoid the spam.
Log 2:
Block was not marked as valid so naturally your node is stuck, likely unreleated issue to Caplin
It happened after i did rm -rf chaindata rm -rf caplin it did try to unwind 1 block (can’t because no diff) and then start spamming logs
It happened after i did rm -rf chaindata rm -rf caplin it did try to unwind 1 block (can’t because no diff) and then start spamming logs
then not caplin's fault, and that does not look like spam to me
After 24hours of work i see in logs:
[INFO] [06-22|19:29:55.039] State processing progress slot=4993570 blk/sec=42.83
what can I do to make this node work? (i did try to do rm -rf chaindata caplin
one more time yesterday).
I have random idea:
maybe erigon did move to snapshots some non-canonical block (and this is reason why Caplin trying to unwind). Now node has v1-020136-020137-headers.seg
file, i will try v1-02013*
just to take a look.
Removal of recent .seg files didn't help. Node still trying to unwind behind block snapshots and fall into long State processing progress
[WARN] [06-23|04:44:19.798] failed to update fork choice err="execution Client RPC failed to retrieve ForkChoiceUpdate response, err: cannot unwind to block 20129999, lowest unwindable block is 18446744073709551615"
...
[INFO] [06-23|11:25:03.792] State processing progress slot=3005881 blk/sec=81.97
node name: snapshotter-bm-e3-ethmainnet-n1
this is not Caplin though, caplin does NOT causes reorg, Caplin tells erigon the correct the chain and Erigon syncs there, If Erigon believes it needs to reorg then i am not sure how to help or how caplin should help
Said that - it is not a caplin bug, caplin just sends an execution block hash to erigon which is close to what the latest hash is, if erigon says, hey we need to reorg, caplin cannot control that
Said that - it is not a caplin bug, caplin just sends an execution block hash to erigon which is close to what the latest hash is, if erigon says, hey we need to reorg, caplin cannot control that
maybe you are right. for now i have 2 mainnet nodes - where on chain-tip i did rm -rf chaindata caplin
and can't sync after it. i didn't investigate deeper yet.
Ok. Seems it was because state files was ahead of block files. Next command helped for me (delete last 1 step in state files):
go run ./cmd/erigon snapshots rm-state-snapshots --step=1564-100000 --datadir=/erigon-data/
what API method using Caplin to understand erigon's progress ?
why are
Ok. Seems it was because state files was ahead of block files. Next command helped for me (delete last 1 step in state files):
go run ./cmd/erigon snapshots rm-state-snapshots --step=1564-100000 --datadir=/erigon-data/
what API method using Caplin to understand erigon's progress ?
Caplin does not understand erigon progress, it just calls FCU to set progress
Btw if we realized there is no bug we should not keep this open
First FCU failing to unwind (because no diffs):
and then node print logs about 2 block nums (with same hashes) in loop: