Fix history sync on testnet & Simplifying history sync artificial checkpoint blocks - #3479
Open
ii-cruz wants to merge 1 commit into
Open
Fix history sync on testnet & Simplifying history sync artificial checkpoint blocks#3479ii-cruz wants to merge 1 commit into
ii-cruz wants to merge 1 commit into
Conversation
ii-cruz
force-pushed
the
iicruz/history-sync-batch-set-gaps-fix
branch
4 times, most recently
from
September 10, 2025 16:15
c0cf848 to
e2217fe
Compare
ii-cruz
marked this pull request as ready for review
September 10, 2025 16:17
ii-cruz
force-pushed
the
iicruz/history-sync-batch-set-gaps-fix
branch
from
September 10, 2025 16:24
e2217fe to
c24fe33
Compare
ii-cruz
force-pushed
the
iicruz/history-sync-batch-set-gaps-fix
branch
from
July 6, 2026 16:52
0a264aa to
e063dcc
Compare
There was a problem hiding this comment.
Pull request overview
This PR simplifies extend_history_sync by tightening the “synthetic checkpoint insertion” logic to the first epoch scenario (where the first checkpoint macro block may have no history items due to delayed reward payouts). It also adds a regression test covering history sync for the first epoch.
Changes:
- Simplify history-sync checkpoint insertion logic in
Blockchain::push_history_sync/extend_history_sync. - Initialize
prev_batchfrom the current chain head instead of assuming0. - Add a new test that syncs the first epoch via (a) first checkpoint then election, and (b) directly to the election block.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| blockchain/src/blockchain/history_sync.rs | Simplifies synthetic macro/checkpoint insertion while extending history during sync. |
| blockchain/tests/history_sync.rs | Adds coverage for syncing the first epoch (checkpoint + election, and direct election). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
ii-cruz
force-pushed
the
iicruz/history-sync-batch-set-gaps-fix
branch
6 times, most recently
from
July 6, 2026 20:22
f1efd54 to
5bd08a2
Compare
ii-cruz
force-pushed
the
iicruz/history-sync-batch-set-gaps-fix
branch
3 times, most recently
from
July 7, 2026 15:31
d23fff5 to
46c6fdd
Compare
ii-cruz
marked this pull request as draft
July 7, 2026 16:32
ii-cruz
force-pushed
the
iicruz/history-sync-batch-set-gaps-fix
branch
from
July 7, 2026 19:44
46c6fdd to
caece00
Compare
ii-cruz
marked this pull request as ready for review
July 7, 2026 20:13
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What's in this pull request?
The extend history for syncing history nodes adds synthetic macro blocks if those are missing, so that it can recreate the
FinalizeBatchinherents before pushing the history of an epoch. However, since we added the reward transactions to the body of the macro blocks, there is only one checkpoint block that can be empty - the first checkpoint block. This is because we pay rewards with a batch delay.The pr #3758 did some hardening for the original assertion. However, it introduced a bug by rejecting the blocks when we have a gap of 2 batches. This shouldn't be the behaviour since we can have a valid code path for a gap, the case where we are in genesis block (batch 0) and batch 1 has no history, so the first item is on batch 2.
This PR:
extend_history_syncFIX MEs and outdated commentsPull request checklist
clippyandrustfmtwarnings.