Prerequisites

• Are you running the latest version(s)?
• Did you check the debugging guide?
• Did you check the FAQs and Discussions?
• Are you reporting to the correct repository?
• Did you search for an existing issue or pull request? --> yes but doesn't seems to answer the issue here (subquery/subql#1203)

Description

[Description of the bug or feature]
I am Running a subquery project for avalanche (https://github.com/subquery/avalanche-subql-starter) - c-type chain, mainnet.
Using RDS database and onfinality API.
The issue is it shows considerable speed when the sync is started and after reaching 100s or 1000s of block sync, the speed starts decreasing as shown below:-

down to 0.0 bps

Even using workers it don't show any change in speed at all. Is the workers implementation not up to mark and still a work-in-progress or it requires some special set of configurations to do beforehand to deal with as database grows, current there are about 2.4Crores of blocks and 40Lacs synced so far with an estimate of days ranging between 30-1000.

Is there something that can be done to trace where the lag is?

Another observation is after sometime (as the database grows, the RPM (request per minute) to onfinality API decrease:-
From this:-

To this:-

Details

These details can help to reproduce the environment the issue is occurring

Local Environment: [You can get this information from executing subql version.] --> @subql/cli/1.8.0 linux-x64 node-v17.2.0
Query Version: [What is the version of the query service?] --> Probably [1.9.0] - 2022-11-30, using this docker image https://hub.docker.com/layers/onfinality/subql-query/latest/images/sha256-d7419524924fd98b91b6ce9dfa8651ca26d34f3cbebaf8db6b5e40221d15b2d8?context=explore,
Indexer Version: [What is the version of the indexer service?] Probably [v1.10.5] (https://hub.docker.com/layers/onfinality/subql-node-avalanche/v1.10.5/images/sha256-02d9b8a4cb27af97a547f58e64444da619dcd82748d5c6ce8531573da37e1bf6?context=explore)
Network Details:

• [Network]-> Mainnet
• [Block height, a block height where the issue is happening]-> I don't think it is related to a block, occurs after like 1000s or 10,000s block synced
• [Dictionary endpoint, if used]--> not used

Steps to Reproduce

1. [First Step]-> clone https://github.com/subquery/avalanche-subql-starter
2. [Second Step]-> go to the folder
3. [and so on...]-> run $npm i from the folder opened in terminal
4. $npm run codegen
5. $npm run build
6. $npm run start:docker

Example project: [A link to a minimal example that can reproduce the issue] --> https://github.com/subquery/avalanche-subql-starter

Expected behavior: [What you expected to happen] --> It should show considerable increase with speed when using workers or if not then at least show consistent speed instead of falling from 3.7K requests per minute to 100s or even 0 requests per minute

Actual behavior: [What actually happened]
the Block sync speed fall down from 40bps to 10-15 then 0bps and block sync time shows 1000days or more to sync.

Any other information

Is there any other information you would like to add?
You can refer database commits per second:-

See https://github.com/subquery/subql/blob/main/packages/node/src/indexer/fetch.service.ts#L134 for reference as to how it should work, for some reason these changes didn't make it from the main sdk

Also of note the filter doesn't include modulo https://github.com/subquery/subql/blob/main/packages/node/src/indexer/fetch.service.ts#L178

When fully synced, avalanche will report being unhealthy. This is because the service expects the block count to increase within a certain time period, but the block production rate means this fails.

We should improve the health check so it doesn't report false positives

Add support for websocket endpoints

Requirements:

• Support OnFinality api keys
• Set the user agent
• Subscribe to new blocks, we should fall back to polling if this is unreliable

Prerequisites

• Are you running the latest version(s)?

Description

Using the standard SubQuery Avalanche Starter project https://github.com/subquery/avalanche-subql-starter
Reported to have only started after the latest release this week

avalanche-subql-starter-subquery-node-1   | 2022-09-29T09:47:37.432Z <nestjs-0> INFO Starting Nest application... 
avalanche-subql-starter-subquery-node-1   | 2022-09-29T09:47:37.723Z <nestjs-0> INFO AppModule dependencies initialized 
avalanche-subql-starter-subquery-node-1   | 2022-09-29T09:47:37.724Z <nestjs-0> ERROR Nest can't resolve dependencies of the IndexerManager (StoreService, ApiService, PoiService, ?, SubqueryProject, NodeConfig, SandboxService, DynamicDsService, DsProcessorService, Subquery, ProjectService). Please make sure that the argument Sequelize at index [3] is available in the FetchModule context.
avalanche-subql-starter-subquery-node-1   | 
avalanche-subql-starter-subquery-node-1   | Potential solutions:
avalanche-subql-starter-subquery-node-1   | - If Sequelize is a provider, is it part of the current FetchModule?
avalanche-subql-starter-subquery-node-1   | - If Sequelize is exported from a separate @Module, is that module imported within FetchModule?
avalanche-subql-starter-subquery-node-1   |   @Module({
avalanche-subql-starter-subquery-node-1   |     imports: [ /* the Module containing Sequelize */ ]
avalanche-subql-starter-subquery-node-1   |   })
avalanche-subql-starter-subquery-node-1   |  
avalanche-subql-starter-subquery-node-1 exited with code 1

Prerequisites

• Are you running the latest version(s)?
• Did you check the debugging guide?
• Did you check the FAQs and Discussions?
• Are you reporting to the correct repository?
• Did you search for an existing issue or pull request?

Description

Should handle avalanche here https://github.com/subquery/subql/blob/75bf3965dfdc574891d7242a18eec469554ff0c9/packages/cli/src/controller/codegen-controller.ts#L190

Details

These details can help to reproduce the environment the issue is occurring

Local Environment: [You can get this information from executing subql version.]
Query Version: [What is the version of the query service?]
Indexer Version: [What is the version of the indexer service?]
Network Details:

• [Network]
• [Block height, a block height where the issue is happening]
• [Dictionary endpoint, if used]

Steps to Reproduce

1. [First Step]
2. [Second Step]
3. [and so on...]

Example project: [A link to a minimal example that can reproduce the issue]

Expected behavior: [What you expected to happen]

Actual behavior: [What actually happened]

Any other information

Is there any other information you would like to add?

Prerequisites

• Are you running the latest version(s)?

Description

When running indexer with workers enabled , there are multiple block ranges that are missing due to fetch service failing

When trying to debug further , in worker.ts file, fetchBlock function is supposed to receive height as number, but sometimes it's receiving it as [number] , and with below fix in that function , the above issue is getting fixed.

async function fetchBlock(height: number): Promise<FetchBlockResponse> {
  assert(workerService, 'Not initialised');
  let hParmas:any;
          if(isArray(height)){
            hParmas=height[0]
          }else{
            hParmas=height
          }
          console.log('-------------------height---------------',hParmas)
  return workerService.fetchBlock(hParmas);
}```