RPC Sync Delay: SubQuery Indexer Node Falling Behind Current Block Height (Up to 30-Minute Lag)

[nitishpatel]

Issue:

The RPC used for running a SubQuery indexer node is blocks behind the actual current block height and is taking up to 30 minutes to catch up.

---

Steps to Reproduce:

1. Clone the Repository:

   git clone [email protected]:subquery/ethereum-subql-starter.git

   Navigate to the directory:

   cd ethereum-subql-starter/XDC/xdc-apothem-starter/

2. Install Dependencies:

   yarn install

3. Update the Configuration:
   Open project.ts and update the startBlock to something recent:

   startBlock: 69941025,

   Also, set the endpoint to:

   endpoint: ["https://erpc.apothem.network"],

---

Observations:

• When unfinalized blocks are not allowed (setting disabled), the indexer syncs 300+ blocks behind.

  • Previously, the indexer synced to the current height within 20 seconds, even with unfinalized blocks disabled.
  • Currently, it takes upwards of 30 minutes to sync.

• After allowing unfinalized blocks, the indexer syncs in 30 seconds as expected.

---

Expected Behavior:

The indexer should sync with the current block height within 20 seconds, as it did previously, regardless of the unfinalized block setting.

---

Environment Details:

RPC: https://erpc.apothem.network

[gzliudan]

May I ask when this issue occurred ?

[jamesbayly]

Hey, this is no good. We're taking a look at it.
@stwiname @yoozo

[jamesbayly]

Hey @nitishpatel perhaps there is some misconception about how the real time indexing works.

SubQuery provides real time indexing of unconfirmed data directly from the RPC endpoint that solves this problem. SubQuery takes the most probabilistic data before it is confirmed to provide to the app. In the unlikely event that the data isn’t confirmed and a reorg occurs, SubQuery will automatically roll back and correct its mistakes quickly and efficiently - resulting in an insanely quick user experience for your customers.

To control this feature, please adjust the --block-confirmations command to fine tune your project and also ensure that historic indexing is enabled (enabled by default)

I suspect the default number of confirmations for your chain is 300 blocks, by controlling the --block-confirmations you should be able to reduce this

[nitishpatel]

Hey @jamesbayly , I will check out with the --block-confirmations flag, However would be good to know if there is something changed recently on the apothem network, because subquery seemed to sync just fine about 8 days back, I started facing the issue post apothem was down for 2 days

[jamesbayly]

We'll check into it. Can you confirm what version of subql-node you are using. it's printed during project startup

[nitishpatel]

The docker image being used is 5.1.4

[gzliudan]

@nitishpatel Did you tested with RPC https://earpc.apothem.network ? This is archive node.

[nitishpatel]

@gzliudan We were using that but then it was going down in between and the also got delisted from https://chainlist.org/?search=apothem

[wanwiset25]

I suspect the default number of confirmations for your chain is 300 blocks, by controlling the --block-confirmations you should be able to reduce this

@jamesbayly How can we find out what is the default confirmation number?

[jamesbayly]

I suspect the default number of confirmations for your chain is 300 blocks, by controlling the --block-confirmations you should be able to reduce this

@jamesbayly How can we find out what is the default confirmation number?

For EVM networks, it is 200 blocks