fix(host-cli): advertise the People genesis the chain reports - #416
Open
TarikGul wants to merge 2 commits into
Open
fix(host-cli): advertise the People genesis the chain reports#416TarikGul wants to merge 2 commits into
TarikGul wants to merge 2 commits into
Conversation
The preset carried `c5af1826...` for paseo-next-v2's People chain; the chain reports `89a63b11...`. Both hashes reached the People chain anyway, because `url_for` answers an unrecognised genesis with `people_ws`, so the drift had no routing symptom. What it did reach was products: `get_chain_info` handed back the stale hash and `PASEO_NEXT_V2_INDIVIDUALITY` exported it, so a product building a People-chain transaction signed `CheckGenesis` over a genesis that chain does not have. The host's own allowance extrinsics were never affected — those read the hash from the chain via `fetch_genesis_hash`. Refreshes the preset, its routing entry, `well-known-chains.ts` and SPEC.md, and drops the fifth copy by importing the constant into `ring-vrf-smoke.ts` the way `ring-vrf-e2e.ts` already does. `served_chain_genesis_hashes_match_the_endpoint_routes` could not catch this: it pins the two constants against each other and both were wrong the same way, as its own doc comment conceded. `the_advertised_genesis_matches_what_each_chain_reports` asks each endpoint for its genesis instead, collecting every mismatch and asserting the checked count so `--ignored` cannot pass on an empty served set. Both genesis tests now resolve the role through `url_for_role`, matched exhaustively so a new `ChainIdentifier` stops compiling rather than surfacing as a panic in an ignored test. Also fixes the `listRingVrfKeys` predicate in `ring-vrf-smoke.ts`, which compared `derivationIndex.tag` against `"Left"`. `DerivationIndex` is `Index | Raw`, so the comparison was always false and the script always threw.
Contributor
|
The same live check currently shows an Asset Hub mismatch that this branch does not yet correct:
|
Member
Author
Assethub should have been corrected in #391. |
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
2 participants
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.
paseo-next-v2's People chain reports
89a63b11…; the preset carriedc5af1826…. The preset, its routing entry,PASEO_NEXT_V2_INDIVIDUALITYand SPEC.md now carry the value the chain reports.The drift had no routing symptom, which is why it survived.
url_foranswers an unrecognised genesis withpeople_ws, so both hashes reached the People chain. Products are where it landed:get_chain_infohands back the advertised hash andPASEO_NEXT_V2_INDIVIDUALITYexports it, so a product building a People-chain transaction signedCheckGenesisover a genesis that chain does not have. The host's own allowance extrinsics read the hash from the chain viafetch_genesis_hashand were never exposed to it.Coverage
served_chain_genesis_hashes_match_the_endpoint_routespins the two constants against each other, and both were wrong the same way. Its replacement,the_advertised_genesis_matches_what_each_chain_reports, asks each endpoint for its own genesis. It collects every mismatch rather than stopping at the first, since a wipe drifts more than one role, and asserts how many roles it checked, because--ignoredruns it without the test that holds the served set non-empty.Both genesis tests resolve a role through
NetworkConfig::url_for_role, matched exhaustively so a newChainIdentifierstops compiling rather than reaching aNonethat only a test run notices.ring-vrf-smoke.tsimports the constant the wayring-vrf-e2e.tsalready does, leaving four hand-maintained definitions of the People genesis, two of them test-pinned. ItslistRingVrfKeyspredicate comparedderivationIndex.tagagainst"Left", andDerivationIndexisIndex | Raw, so the comparison was always false and the script always threw. It passes for the first time here.Verification
Live against paseo through the CLI: the new test matches all three served roles and fails when the stale hash is restored,
battery.sh --signing-hostruns the ring-VRF registry e2e green,ring-vrf-smoke.tsreportsRING_VRF_OK, andsmart-contract-allowance-smoke.tsreportsAllocated.