Support forking a custom relay chain - #137
Conversation
| /// For a relay that is not a public network use: | ||
| /// custom%<name>%<rpc_endpoint>%<chain_spec_path> | ||
| #[arg(short = 'r', long = "rc", verbatim_doc_comment)] |
There was a problem hiding this comment.
We are dropping the help msj here with the possible values. I think we should include it.
There was a problem hiding this comment.
restored, lists the four networks plus the custom format
| { | ||
| let relaychain = if relay_network.starts_with("custom%") { | ||
| resolve_custom_relaychain(&relay_network, relay_runtime.clone(), relay_bite_at)? | ||
| } else if relay_runtime.is_some() || rc_sync_url.is_some() || relay_bite_at.is_some() { |
There was a problem hiding this comment.
But here we support more strings that may not start with custom%, I think we need to ensure is a valid rc.
There was a problem hiding this comment.
now bails on anything that isn't a known network or custom%. Kept the permissive mapping only in Relaychain::new for the helper subcommands that only get a name back
| /// `id` of a chain-spec, which is the directory the node stores its db under. | ||
| async fn spec_chain_id(spec_path: &str) -> Option<String> { | ||
| let content = fs::read_to_string(spec_path).await.ok()?; | ||
| let spec: serde_json::Value = serde_json::from_str(&content).ok()?; | ||
| spec["id"].as_str().map(str::to_string) | ||
| } | ||
|
|
There was a problem hiding this comment.
This looks weird, we are returning an Option and do not emitting errors when we can't read the chain-spec from the spec_path and if we can read but is not a valid json format. I think if any of those two fails we should report the error since that will make something fail down the road.
WDYT?
There was a problem hiding this comment.
made it a Result with separate errors for unreadable / bad json / missing id, propagated at the call site
|
@pepoviola heads up, three more commits landed here after your review, all from actually forking public paseo with this branch (custom relay + PPN's next paras)
worth a second look at those three before this merges |
|
@pepoviola I ran this branch against real networks end to end Kusama relay + Asset Hub forked in ~20 min:
four fixes came out of the runs, all in this PR:
|
2 participants
Stacked on #129, and includes #135's change (a custom relay has to be able to supply its endpoint, so the two overlap).
-r custom%<name>%<rpc_endpoint>%<chain_spec_path>forks a relay zombie-bite has no built-in knowledge of. The name is what artifacts are named after, the endpoint is what state and metadata are read from, and the spec is what the node is started with (--chain <spec>instead of a network name). There is no built-in host config for such a relay, soConfiguration::ActiveConfighas to come from the endpoint — the bite fails with that reason if it can't.A relay name outside
polkadot/kusama/paseo/westendis now a custom relay instead of silently falling back to polkadot. That is what lets the helper subcommands (generate-artifacts,clean-up-dir), which only get the name back as a string, keep naming a custom relay's artifacts correctly — and a typo'd name now fails instead of biting the wrong chain.The node stores its db under the chain-spec's own
id, which need not match the artifact name, so the snapshot path is resolved from the spec.Closes #133
Closes #134
Also fixes
ParaScheduler::ValidatorGroupsshape: one group per core with validators round-robined, instead of one group per validator. The old shape (always cores+1 groups) wedges the scheduler/approval subsystems on a live fork and finality stays pinned at the bite block - found by forking public paseo and comparing against preview-net's working bites. Requesting more cores than the dev validators can staff is now an error