Sync change of behavior

[zhk101]

Geth version: Version: 1.4.6 Git Commit: https://github.com/bnb-chain/bsc/commit/43b2ffa63ba242437bcf19ee9bccf9595be0763a Git Commit Date: 20240429 Architecture: amd64 Go Version: go1.21.6 Operating System: linux

cmd

geth --history.transactions=0 --syncmode=full --tries-verify-mode=none --db.engine=pebble --metrics --metrics.addr "0.0.0.0" --http --graphql --cache=16384 --config conf.toml

conf.toml

[Eth]
NetworkId = 56
SyncMode = "full"
DiffBlock = 5000
TransactionHistory = 0
LightPeers = 100
TrieTimeout = 150000000000
TriesVerifyMode = "none"

[Eth.Miner]
GasCeil = 140000000
GasPrice = 1000000000
Recommit = 10000000000

[Eth.TxPool]
Locals = []
NoLocals = true
Journal = "transactions.rlp"
Rejournal = 3600000000000
PriceLimit = 1000000000
PriceBump = 10
AccountSlots = 200
GlobalSlots = 8000
AccountQueue = 200
GlobalQueue = 4000

[Eth.GPO]
Blocks = 20
Percentile = 60
MaxHeaderHistory = 5
MaxBlockHistory = 5
OracleThreshold = 1000

[Node]
DataDir = "geth.fast"
IPCPath = "geth.ipc"
InsecureUnlockAllowed = false
DBEngine = "pebble"


[Node.P2P]
MaxPeers = 512
MaxPeersPerIP = 512
NoDiscovery = false
StaticNodes = []
EnableMsgEvents = false

Starting node from BNB48 snapshot: 38198925 (Apr-26-2024 01:38:27 PM +UTC) https://snapshots.48.club/geth.fast.38198925.tar.zst

This is relates to #2394 Looks like the sync subscription now returns sync=false only when prog.CurrentBlock >= prog.HighestBlock and txIndexRemainingBlocks == 0.

Using eth.syncing in geth console, txIndexRemainingBlocks never seem to change on my node, even when it reached a state of prog.CurrentBlock >= prog.HighestBlock resulting in the sync subscription still returning syncing=true. Is this something that will always happen on a fast-node (using the fast-node BNB48 snapshot). Will this value eventually go down?

Previous to 1.4.X, this never seem to be an issue, and the node managed to sync correctly

[zhk101]

it has been reported as well in one of the closed issues of the bnb48 snapshot repo, here https://github.com/48Club/bsc-snapshots/issues/150#issue-2261308800 I do see the same value txIndexRemainingBlocks: 33602365 in my node and that value doesn't change at all. txIndexFinishedBlocks keeps on increasing tho.

[zzzckck]

it has been reported as well in one of the closed issues of the bnb48 snapshot repo, here 48Club/bsc-snapshots#150 (comment) I do see the same value txIndexRemainingBlocks: 33602365 in my node and that value doesn't change at all. txIndexFinishedBlocks keeps on increasing tho.

could you try --history.transactions=90000? the snapshot of 48Club may only contain the most recent 90K blocks, it could failed the tx index process.

[zhk101]

I did try yes but that txIndexRemainingBlocks doesn't budge.

I switched to using the full node (the 800gb one) with pbss (instead of hash-based) and it works fine. Also changed trie-verify-node to none instead of the default local value for that snapshot

Still feels like there is a regression here as I've been using the fast node snapshot without issues prior to 1.4.x

[zhk101]

Btw, I was using the BNB48 fast snapshot that was done with 1.4.5, on my 1.4.6 node. Yesterday saw this https://github.com/48Club/bsc-snapshots/issues/151#issuecomment-2102135151 And also, this might be related to https://github.com/bnb-chain/bsc/issues/2437

[sysvm]

Btw, I was using the BNB48 fast snapshot that was done with 1.4.5, on my 1.4.6 node. Yesterday saw this 48Club/bsc-snapshots#151 (comment) And also, this might be related to #2437

Do you mean it's ok in geth v1.4.5, but not work in geth v1.4.6?

[zhk101]

Just assuming here, pointing at a comment I saw from the BNB48 snapshot publisher explicitly saying the need to use 1.4.5 for the snapshot. I haven't tried that snapshot with 1.4.5 tbh, only with 1.4.6 and it failed. Thought it might give you guys some clues.

[sysvm]

@du5 I have two questions:

• Can you give me the detailed info about the snapshot version that you are using? Or how can I reproduce this error?
• How do you make fastnode snapshot of 48Club?

[jingjunLi]

Hi @du5 , Could you answer the following questions to help us locate the issue:

• Can you provide the specific config.yaml & run cmd to reproduce issue #2437 , such as which snapshot was used, what commands were executed specifically, and what the exact run instructions were?
• Do both hash and pbss have the same issue after snapshot prune-block?
• Why close #2437 and move the replies here?

[du5]

Hi @du5 , Could you answer the following questions to help us locate the issue:

• Can you provide the specific config.yaml & run cmd to reproduce issue [BUG] Unexpected error when getting snapshot after prune #2437 , such as which snapshot was used, what commands were executed specifically, and what the exact run instructions were?
• Do both hash and pbss have the same issue after snapshot prune-block?
• Why close [BUG] Unexpected error when getting snapshot after prune #2437 and move the replies here?

After testing, I reproduced the problem, it's not related to #2437. At first I thought it was prune that caused the failure to synchronize. #2437 is solved now

[zhk101]

Ok so tried again with the latest fast node snapshot @du5 just released yersterday, on the same configuration mentioned above and the node is still synching for-ever because of txIndexRemainingBlocks: 33602365 `

eth.syncing { currentBlock: 38769531, healedBytecodeBytes: 0, healedBytecodes: 0, healedTrienodeBytes: 0, healedTrienodes: 0, healingBytecode: 0, healingTrienodes: 0, highestBlock: 38769471, startingBlock: 38769467, syncedAccountBytes: 0, syncedAccounts: 0, syncedBytecodeBytes: 0, syncedBytecodes: 0, syncedStorage: 0, syncedStorageBytes: 0, txIndexFinishedBlocks: 5167167, txIndexRemainingBlocks: 33602365 } `

[zhk101]

Ok so for the sake of it I tried again what @zzzckck mentioned about specifying --history.transactions=90000. I could swear I tried at the time without success. Anyway, restart the node changing --history.transactions=0 with --history.transactions=90000 and then I could see a log saying Unindexing transactions. Once it picked up again the few last blocks, the node finally managed to sync up correctly! 🙌 @du5 maybe this is something you should now change in the node params for the fast node in the BNB48 README?