MIssing Blocks and Transactions
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 2
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
There are three gaps in our blocks and transactions table identified with:
WITH all_numbers AS (
SELECT generate_series(MIN(18562218), MAX(19316649)) AS num
FROM blocks
),
missing_blocks as (SELECT an.num
FROM all_numbers an
LEFT JOIN blocks yt ON an.num = yt.number
WHERE yt.number IS NULL)
-- select count(*) from transactions where block_number in (select num from missing_blocks);
-- select * from erc721_transfer where block_number in (select num from missing_blocks);
The results are in three isolated chunks:
- (200 blocks) from 18562220 to 18562419
- (200 blocks) from 18562520 to 18562719
- (50 blocks) from 18844270 to 18844319
The logs for this are too old to recover.
I propose clear the DB from 18562220 and let it repopulate. This would give us the opportunity to see whats went wrong and shouldn't take too long to recover from (i.e. November 13 2023)
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No file or test entry point is named. Start by running the supplied SQL against the blocks table and inspect the indexer's database-repopulation path; the issue notes that historical logs cannot recover the gaps. Done means the database is safely repopulated from block 18562220 and the three missing ranges, transactions, and ERC-721 transfers are verified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, sql
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100