test(integration): TestGigaMixedRelease — giga vs v2 read parity under conformance load#489
Merged
Conversation
…r conformance load
Proves giga_store_migration.md's central safety claim ("Giga SS Store is a
per-node SS change that is invisible to the network") with real load
instead of a healthy-boot check. Provisions one 4-validator chain with
two plain RPC followers, migrates one follower to giga (evm-ss-split=true)
via the same StateSync recipe TestGigaStoreMigration drives, leaves the
other at the shipped default (ss-enable=true ships on every node already;
evm-ss-split=false is the only thing distinguishing "giga"), then runs
the external release-test conformance harness (749 cases) against both
followers concurrently under separate funded admin accounts, so the two
runs never race a shared account's tx sequence.
waitJobErr mirrors the existing waitJob polling loop but returns an error
instead of calling t.Fatalf, so the two harness waits can run in
goroutines (T.FailNow, which Fatalf calls, must only run on the test's
own goroutine; job/secret creation and t.Cleanup registration stay on the
main goroutine, only the wait-and-log step is concurrent).
Honest ceiling documented in the test: the release-test image is
external/opaque, so global-state cross-talk between the two concurrent
runs can't be fully ruled out from this side; the noted fallback is
running the two harness Jobs sequentially if that's ever observed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Bugbot is paused — on-demand spend limit reachedBugbot uses usage-based billing for this team and has hit its on-demand spend limit. A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue. |
Round-1 review, both lenses independently: the fixture provisioned validators with releaseBaseConfig (no snapshot production), but the migration workflow wipes rpcNodes[1] and re-bootstraps it via CometBFT state-sync — with nothing producing a snapshot, catch-up depended on the chain organically reaching the sei-config default interval (2000 blocks), an unstated and fragile dependency the sibling state-sync tests' own comments name as load-bearing. Fix: overlay snapshotProductionConfig on the validators (interval 50, the same config bringUpStateSyncFollower uses), zero it on both followers (rpcConfig; a follower is a witness, not a producer), and add the matching WaitHeightAdvances gate before the migration workflow so a snapshot demonstrably exists first. Also adds the witness-freshness gate the sibling fixture applies (catching_up is a one-way latch, so a diverging witness would otherwise fail the migration's light-client cross-check opaquely instead of at a named gate) and moves the JobFailed-path log read onto a fresh context, matching the deadline-path read already in waitJobErr. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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.
Summary
Adds a nightly integration suite that demonstrates giga_store_migration.md's central safety claim under real load: "Giga SS Store is a per-node SS change that is invisible to the network."
TestGigaStoreMigrationalready proves the migration mechanics (wipe, resync, config-patch anchor, healthy boot); this test proves the read/write behavioral parity the doc claims, by running the same 749-case release conformance harness against a giga node and a plain (v2) node side by side.TestRelease's fixture).evm-ss-split=true) via the existing StateSync+GigaStore workflow — the other stays at the shipped default (every node shipsss-enable=truealready;evm-ss-split=falseis the only thing distinguishing "giga").Design note
waitJobErrmirrors the existingwaitJobpolling loop but returns an error instead of callingt.Fatalf, since it runs in a goroutine (only the test's own goroutine may callT.FailNow). Job/Secret creation andt.Cleanupregistration stay on the main goroutine; only the wait-and-log step is concurrent.Honest ceiling, documented in the test doc comment: the release-test image is external/opaque to this suite — if any of its 749 cases assert global chain state (vs. state scoped to their own admin account), concurrent runs could in principle cross-talk in a way neither log explains. Noted fallback: run the two harness Jobs sequentially instead of concurrently if that's ever observed.
Status
Compiles clean (
go test -c -tags integration), discovered by-list, gofmt/vet clean. Not yet run against a live cluster — this PR is out for a kubernetes-specialist + sei-network-specialist review pass first (the concurrent-harness-against-shared-chain shape is new territory), and a full run is ~80-100 minutes of cluster time. Will report the first live run's result before requesting merge.🤖 Generated with Claude Code