[blockindex] introduce indexergroup

[envestcc]

Description

Currently, when the node starts up, each block indexer is checked separately, meaning that one indexer will only be checked when it reaches the tip height before another indexer is checked. However, the contract staking indexer and factory indexer are not completely independent, and checking them separately may cause block validation failures. Therefore, these two indexers need to be checked synchronously.

To address this, we introduce the IndexerGroup, which is a special indexer that can contain other indexers. Indexers added to the IndexerGroup can support synchronous checking.

Fixes #(issue)

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• [] Code refactor or improvement
• [] Breaking change (fix or feature that would cause a new or changed behavior of existing functionality)
• [] This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• make test
• [] fullsync
• [] Other test (please specify)

Test Configuration:

• Firmware version:
• Hardware:
• Toolchain:
• SDK:

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[Liuhaai]

Currently, when the node starts up, each block indexer is checked separately, meaning that one indexer will only be checked when it reaches the tip height before another indexer is checked.

Should the issue be fixed here instead?
https://github.com/iotexproject/iotex-core/blob/v1.11.0/blockchain/blockdao/blockdao.go#L95-L115
loop at each height not each indexer.
Another option is that the factory indexer is put at the end of the array of indexers, since the factory indexer depends on the contract indexer

[envestcc]

Should the issue be fixed here instead? https://github.com/iotexproject/iotex-core/blob/v1.11.0/blockchain/blockdao/blockdao.go#L95-L115 loop at each height not each indexer.

Yeah, it's another workable solution. However, using IndexerGroup is a more simple way to reduce modifications to existing code.

[codecov]

Codecov Report

Merging #3906 (8a1df8e) into master (e1f0636) will increase coverage by 0.64%.
Report is 79 commits behind head on master.
The diff coverage is 73.27%.

❗ Current head 8a1df8e differs from pull request most recent head 9efc47c. Consider uploading reports for the commit 9efc47c to get more accurate results

@@            Coverage Diff             @@
##           master    #3906      +/-   ##
==========================================
+ Coverage   75.38%   76.02%   +0.64%     
==========================================
  Files         303      328      +25     
  Lines       25923    27878    +1955     
==========================================
+ Hits        19541    21194    +1653     
- Misses       5360     5588     +228     
- Partials     1022     1096      +74     

Files Changed	Coverage Δ
action/protocol/execution/evm/evm.go	43.52% <0.00%> (-2.95%)	⬇️
action/protocol/execution/evm/evmstatedbadapter.go	66.77% <ø> (ø)
action/protocol/poll/consortium.go	0.00% <0.00%> (ø)
action/protocol/poll/staking_committee.go	43.85% <0.00%> (ø)
...tion/protocol/staking/contractstake_bucket_type.go	0.00% <0.00%> (ø)
action/receipt.go	82.17% <ø> (ø)
api/grpcserver.go	86.40% <0.00%> (ø)
api/loglistener.go	25.00% <0.00%> (ø)
api/websocket.go	4.10% <0.00%> (-1.07%)	⬇️
blockchain/config.go	74.54% <ø> (ø)
... and 65 more

... and 4 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[Liuhaai]

Should the issue be fixed here instead? https://github.com/iotexproject/iotex-core/blob/v1.11.0/blockchain/blockdao/blockdao.go#L95-L115 loop at each height not each indexer.

Yeah, it's another workable solution. However, using IndexerGroup is a more simple way to reduce modifications to existing code.

Around 30 lines of change should have done the work d6331c6

[envestcc]

Around 30 lines of change should have done the work d6331c6

Yes, in terms of the amount of code modification, this way is less. However, its actual impact is significant, as it affects all indexers with a greater risk of encountering issues and requiring more extensive testing. On the other hand, introducing indexergroup has no impact on other indexers in comparison.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
3 Code Smells

No Coverage information
0.0% Duplication