services/horizon: Check state rebuild in state verification integration test #3127
Conversation
…o integration-state-rebuild
services/horizon/internal/integration/protocol14_state_verifier_test.go
Outdated
Show resolved
Hide resolved
services/horizon/internal/integration/protocol14_state_verifier_test.go
Outdated
Show resolved
Hide resolved
services/horizon/internal/integration/protocol14_state_verifier_test.go
Outdated
Show resolved
Hide resolved
bartekn
changed the title
bartekn
changed the title
| for !itest.LedgerIngested(thirdCheckpoint) { | ||
| t.Log("Third checkpoint ledger not ingested yet...") | ||
| time.Sleep(5 * time.Second) | ||
| } |
There was a problem hiding this comment.
Wait, okay so now that I understand the checkpoint thing a little more, why do we check for secondCheckpoint, then thirdCheckpoint, and only then do the state verification? It seems the check for the second is redundant, no? Since it has to wait for the third as the next step, and third implies second.
There was a problem hiding this comment.
Ingestion is running a state machine (fsm.go file). During normal Horizon operations with usually stay in resumeState all the time. However, horizon ingest trigger-state-rebuild command makes the machine jump to startState. There, we fall into the case that makes us wait for the next checkpoint. Why? It's because after the first checkpoint and state verification we're at ledger above 63. But the last checkpoint is still 63. So we wait for the network to close the second ledger to be able to catchup. This won't trigger state verification because it's triggered from resumeState only. That's why we need to wait for the third checkpoint.
bartekn
changed the title
PR Checklist
PR Structure
otherwise).
services/friendbot, orallordocif the changes are broad or impact manypackages.
Thoroughness
.mdfiles, etc... affected by this change). Take a look in the
docsfolder for a given service,like this one.
Release planning
needed with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
Recreating because #3102 was removed because I removed a release branch.
What
Check state rebuild in state verification integration test.
Why
All integration tests start from empty state so we don't test building state from history archives. Extended state verification integration test to trigger state rebuild (
horizon expingest trigger-state-rebuild) and verify rebuild state again. Such test would catch the bugs like #3100 and #3096.Known limitations
It will make the test 3x slower so let's merge it after moving integration tests to nightly runs.