paritytech / paritytech/playground-cli
descriptors.ts selectors ignore their `env` arg — silent wrong-descriptor risk if a second env is wired
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 5
- Forks
- 12
- PR merge metrics
- No merged PRs in 30d
Description
Summary
Since #465, the three descriptor selectors in src/utils/descriptors.ts
(getAssetHubDescriptor / getBulletinDescriptor / getIndividualityDescriptor)
ignore their env parameter and unconditionally return the paseo-* descriptor.
This is safe today, but it is a latent footgun: the correctness of the selectors
depends on an implicit invariant enforced in a different file.
Background
@parity/product-sdk-descriptors@0.8.0 dropped the summit-* descriptor
subpaths (and summit was retired), so the selectors no longer branch per env —
they return the fixed paseo constants and discard the env arg:
export function getAssetHubDescriptor(_env: Env | undefined): AssetHubDescriptor {
return paseo_asset_hub;
}
export function getBulletinDescriptor(_env: Env | undefined): BulletinDescriptor { … }
export function getIndividualityDescriptor(_env: Env | undefined): IndividualityDescriptor { … }
The risk
getConnection() (src/utils/connection.ts) builds the direct PAPI clients from
getAssetHubDescriptor(getChainConfig().env) (and the bulletin/individuality
equivalents). Because the env arg is discarded, "always return paseo" is only
correct while paseo-next-v2 is the sole env wired in CONFIGS.
If someone later wires a second env into CONFIGS (e.g. polkadot, which is
already present in ENV_IDS) without also editing descriptors.ts, direct
reads would decode that chain's state with the paseo descriptor — silently
wrong metadata, with no error raised. The only thing preventing this today is
getChainConfig() throwing for any env not in CONFIGS — an implicit safety net
one file away from the code that relies on it.
Proposed fix
Make the selectors fail loud instead of silently returning paseo for an
unexpected env: assert the requested env resolves to a paseo-family descriptor
(or that it is the wired default) and throw otherwise. ~3 lines; converts the
latent footgun into an immediate, obvious error the moment a second env is wired.
Restore real per-env selection here if/when another env ships dedicated
descriptors upstream.
Context
Surfaced by the #465 code review (altitude / latent-correctness finding).
Not a live bug — only paseo-next-v2 is wired today, and tsc + the
config.test.ts divergence guard both hold. Filed as hardening / tech-debt.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in src/utils/descriptors.ts by reading the three selectors and their paseo descriptor imports, then trace the env passed from src/utils/connection.ts. Ensure unexpected environments fail loudly while the wired paseo environment remains valid, and run tsc plus the config.test.ts divergence guard to verify the change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100