fix(host-cli): advertise the People genesis the chain reports - #416
Merged
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.
Member
Author
Assethub should have been corrected in #391. |
Review found a mutation the whole suite accepted: point People at Bulletin's genesis and URL, and every assertion agrees. The constants match each other, the role routes to the URL the preset names, and the live check passes because the Bulletin endpoint truthfully reports the hash it was handed. Nothing tied a role to the identity of the chain behind it, so the live test claimed more than it showed. It now reads `system_chain` and requires the name to carry the role. Unreachable endpoints are collected rather than panicked on. People is probed first, so one unreachable RPC aborted before Bulletin or Asset Hub were seen, which is the outcome the "collect every mismatch" design paragraph exists to avoid, and a connection error read identically to real drift. The probe count is derived from the served set instead of a hardcoded three, so adding a role widens the test rather than failing it, with non-emptiness asserted separately because a derived count cannot notice a set that shrank to nothing. Adds the guard the change most needed and did not have: nothing tied `well-known-chains.ts` to the preset, and products sign `CheckGenesis` over the TypeScript constant, not over anything in this crate. It is compiled in with `include_str!`, so a renamed export breaks the build rather than drifting.
filvecchiato
approved these changes
Aug 16, 2026
Imod7
approved these changes
Aug 16, 2026
Asserting them separately meant one unreachable endpoint discarded every drift the answering endpoints had already proven, and then claimed drift was unproven when it was not. Both are collected into one failure, drift first. Pins SPEC.md's §14.1 table the same way as `well-known-chains.ts`. It is the fourth hand-maintained copy of these hashes and the only one covering Bulletin, since the TypeScript exports People and Asset Hub but no Bulletin constant.
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Aug 16, 2026
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
3 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.