You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There were 4 of testnet nodes running 2.5.0-rc.1 affected. Note it may be different issues on them.
The nodes fail to do block sync getting stuck at some blocks.
Main issue is the snapshot producing node failed to sync up after the last snapshot was uploaded.
The node fails to sync up with the following error message:
Feb 22 13:30:44 node-ft01 nearcore[263250]: 2025-02-22T13:30:44.513565Z WARN chain: Error in applying chunk for block shard_id=9 hash=J4yP1KAL57RvCnCbsyjn1jtmj636cxfEePzooxkUmVTs err=Storage Error: MissingTrieValue(TrieStorage, XMuesBVj3SqcHXSrWax4Ca6TjKivHpMgUwXdjcwPGJU)
Feb 22 13:30:44 node-ft01 nearcore[263250]: 2025-02-22T13:30:44.513630Z ERROR client: try_process_unfinished_blocks got errors errors={J4yP1KAL57RvCnCbsyjn1jtmj636cxfEePzooxkUmVTs: StorageError(MissingTrieValue(TrieStorage, XMuesBVj3SqcHXSrWax4Ca6TjKivHpMgUwXdjcwPGJU))}
The team narrowed down the issue to garbage collection on the newly created shard (9). This problem only occurs on rpc nodes.
We are working on the fix so that it does not happen in future reshardings.
If you are affected by this, you can mitigate the issue by getting the good state by either Epoch Sync or restore the node from one of the latest FastNEAR snapshots.
Thanks @evgenykuzyakov for being proactive in facilitating the recovery!
Epoch Sync:
./neard init --download-config rpc --chain-id testnet --download-genesis
curl -X POST https://rpc.testnet.near.org -H "Content-Type: application/json" -d '{
"jsonrpc": "2.0",
"method": "network_info",
"params": [],
"id": "dontcare"
}'| jq -r '.result.active_peers[] as $active_peer | "\($active_peer.id)@\($active_peer.addr)"' |paste -sd',' -
# put the output in configs.
./neard run
Archival node got affected as well. Not sure how to recover this yet. I assume I should be able to download older hot snapshots from regular RPC and then sync properly once the GC issue is fixed.
EDIT: Solved that using latest RPC snapshot. Converted it to Hot. Advanced it a bit to have HEAD later than previous cold-data HEAD. Than it was able to sync up. Will upload a new archive snapshot now.
Contact Details
[email protected]
Node type
RPC
Which network are you running?
testnet
What happened?
There were 4 of testnet nodes running 2.5.0-rc.1 affected. Note it may be different issues on them.
The nodes fail to do block sync getting stuck at some blocks.
Main issue is the snapshot producing node failed to sync up after the last snapshot was uploaded.
The node fails to sync up with the following error message:
Reproduce steps
It's easy to reproduce the state using the snapshot from block
188313698
(details https://docs.fastnear.com/docs/snapshots#rpc-testnet-snapshot):Version
Relevant log output
Node head info
Node upgrade history
DB reset history
The node was producing snapshots for FastNear testnet.
The text was updated successfully, but these errors were encountered: