Problem
Features::supported_chains (truapi-platform/src/lib.rs:548-550):
Enumerate the chains this host serves (RFC 0026). The returned set must match exactly
what [ChainProvider::connect] will accept; the core resolves get_chain_info requests
against it.
The returned HostChainSet (:530) is keyed by ChainIdentifier, a closed enum of four
roles — Relay | AssetHub | People | Bulletin (truapi/src/v01/chain.rs:362-371). Read
strictly, a host can serve only four chains.
That contradicts ChainProvider::connect (:561-568), which takes an arbitrary
genesis_hash: [u8; 32], and feature_supported, which probes by arbitrary genesis hash
too. Polkadot Desktop's chain list comes from remote config and products connect to chains
holding no well-known role, so the host is currently guessing whether that is legal.
For comparison, the hand-written host has no role enum at all: every chain call in
@novasamatech/host-api is keyed by an arbitrary
genesisHash: Hex(),
and support is probed with
Feature = Enum({ Chain: Hex() }).
An open-ended, hash-addressed chain set is what a host in production actually serves.
Possible solving path
Depends on the intent, which is what this issue is really asking.
If connect is unconstrained and the set only scopes get_chain_info, the comment is the
bug — it should say the set does not bound connect.
If it is constrained, the set needs to express chains beyond the four roles: either an
Other { genesis_hash } variant on ChainIdentifier, or an additional_chains: Vec<Bytes32> field alongside chains.
Verified against paritytech/truapi@7811017d (published @parity/truapi@0.9.0 / @parity/truapi-host@0.6.0, plus two commits). Citations are Rust source, since the TS host contract is gitignored codegen output.
Problem
Features::supported_chains(truapi-platform/src/lib.rs:548-550):The returned
HostChainSet(:530) is keyed byChainIdentifier, a closed enum of fourroles —
Relay | AssetHub | People | Bulletin(truapi/src/v01/chain.rs:362-371). Readstrictly, a host can serve only four chains.
That contradicts
ChainProvider::connect(:561-568), which takes an arbitrarygenesis_hash: [u8; 32], andfeature_supported, which probes by arbitrary genesis hashtoo. Polkadot Desktop's chain list comes from remote config and products connect to chains
holding no well-known role, so the host is currently guessing whether that is legal.
For comparison, the hand-written host has no role enum at all: every chain call in
@novasamatech/host-apiis keyed by an arbitrarygenesisHash: Hex(),and support is probed with
Feature = Enum({ Chain: Hex() }).An open-ended, hash-addressed chain set is what a host in production actually serves.
Possible solving path
Depends on the intent, which is what this issue is really asking.
If
connectis unconstrained and the set only scopesget_chain_info, the comment is thebug — it should say the set does not bound
connect.If it is constrained, the set needs to express chains beyond the four roles: either an
Other { genesis_hash }variant onChainIdentifier, or anadditional_chains: Vec<Bytes32>field alongsidechains.Verified against
paritytech/truapi@7811017d(published@parity/truapi@0.9.0/@parity/truapi-host@0.6.0, plus two commits). Citations are Rust source, since the TS host contract is gitignored codegen output.