BSC archival node behind by 17k blocks


Our app is using speedy node web3 provider for BSC archieve (using this URL:${key}/bsc/mainnet/archive)
Recently we have noticed that it is behind by 17k blocks compared to blocks in the bscscan.
Our app has been affected by this functionality. Can we have a support for this issue?

Thank you.

we know about this problem, we are working on it, it was a hard fork recently on BSC that caused some problems

@cryptokid Would be lovely I you could inform us once the issue is resolved. Thanks!

1 Like

Also it would be lovely if there is a way to retrieve the current sync status of the node. A simple web3.eth.isSyncing does not work for me.

we have this status page for now:

I appreciate this (I also found this page). But it would be more helpful to know how much the nodes are exactly behind so see an average. My product heavily depends on being with the live flow on the chain. It is just a suggestion. For now I will try to pull the sync state from the status page.

It seems to be quite okay now. The status dashboard shows no sycing activity anymore but I still struggle to get balances on block heights of the last hour or so. getBlockNumber returns always null. Is there a way to find out to what block number the archive is available?

we are still working on syncing BSC archive nodes

1 Like

EDIT: Nevermind, I have seen your post in the other thread. Seems like have to wait more then.

Is there any update or estimate on this? Requesting the last available block returns a block which is at least 40000 blocks behind the current one and it seems to be increasing slowly.

Probably depending on which internal node on your side is working on the request, the block number difference jumps from 40k to 64k difference to the current one.