Priority: P2 — CI / test plumbing only, no end-user impact
cc @mordamax for e2e-architecture input.
Problem
@parity/product-sdk-bulletin's BulletinClient routes through the Polkadot host's preimage subscription (`@parity/product-sdk-chain-client` `createProvider` requires a host container). This makes the client unusable from Node-only environments — CI scripts, build pipelines, test harnesses — even though those callers have the seed and could legitimately upload to Bulletin.
Repro
Run any Node script that does `BulletinClient.create(...)` outside Polkadot Desktop / Browser. Example from `paritytech/playground-app` `scripts/publish-metadata.ts` running in GitHub Actions:
```
Error: Host provider unavailable for chain 0x173cea9df45656cf612c8b8ece56e04e9a693c69cfaac47d3628dae735067af8.
Ensure you are running inside a host container (Polkadot Browser / Desktop).
at createProvider (.../@parity/product-sdk-chain-client/dist/index.js:9:11)
at async initChainClient (...)
at async Function.create (.../@parity/product-sdk-bulletin/src/client.ts:123:27)
at async (.../scripts/publish-metadata.ts:130:16)
```
(Workflow run: https://github.com/paritytech/playground-app/actions/runs/26057580200 — the script publishes the playground-app's own registry metadata after each deploy; it's CI plumbing, not user-facing.)
End-user impact
None. The browse path (inside Polkadot Desktop/Mobile) is fine — host container is always present. `dot deploy --playground` is fine — the CLI mirrors `bulletin-deploy`'s dedicated-client pattern. RevX is fine — uses `bulletin-deploy` directly. The only affected paths are Node-side scripts that talk to Bulletin without a host.
Existing workaround pattern
`paritytech/playground-cli` already mirrors this pattern in `src/utils/deploy/playground.ts` for the metadata upload — builds a dedicated Bulletin client with a 300s heartbeat instead of going through the shared (now host-only) chain client. That pattern works but each consumer has to reinvent it.
What would unblock CI-side callers
Either:
- A Node-callable client constructor in `@parity/product-sdk-bulletin` that accepts a WS endpoint + seed and skips the host-provider lookup — same surface, different transport.
- A documented, exported helper for the dedicated-client pattern so consumers stop hand-rolling it.
Option 1 is preferred — fewer foot-guns, fewer per-consumer copies of the chain-client config.
Per the playground.dot v0.12 spec
The Summit devnet (and Paseo Next v2 today) is the active V1 network — this gap will hit any project that needs to refresh registry metadata, run E2E publish flows from a Node test harness, or do post-deploy verification from CI.
Priority: P2 — CI / test plumbing only, no end-user impact
cc @mordamax for e2e-architecture input.
Problem
@parity/product-sdk-bulletin'sBulletinClientroutes through the Polkadot host's preimage subscription (`@parity/product-sdk-chain-client` `createProvider` requires a host container). This makes the client unusable from Node-only environments — CI scripts, build pipelines, test harnesses — even though those callers have the seed and could legitimately upload to Bulletin.Repro
Run any Node script that does `BulletinClient.create(...)` outside Polkadot Desktop / Browser. Example from `paritytech/playground-app` `scripts/publish-metadata.ts` running in GitHub Actions:
```
Error: Host provider unavailable for chain 0x173cea9df45656cf612c8b8ece56e04e9a693c69cfaac47d3628dae735067af8.
Ensure you are running inside a host container (Polkadot Browser / Desktop).
at createProvider (.../@parity/product-sdk-chain-client/dist/index.js:9:11)
at async initChainClient (...)
at async Function.create (.../@parity/product-sdk-bulletin/src/client.ts:123:27)
at async (.../scripts/publish-metadata.ts:130:16)
```
(Workflow run: https://github.com/paritytech/playground-app/actions/runs/26057580200 — the script publishes the playground-app's own registry metadata after each deploy; it's CI plumbing, not user-facing.)
End-user impact
None. The browse path (inside Polkadot Desktop/Mobile) is fine — host container is always present. `dot deploy --playground` is fine — the CLI mirrors `bulletin-deploy`'s dedicated-client pattern. RevX is fine — uses `bulletin-deploy` directly. The only affected paths are Node-side scripts that talk to Bulletin without a host.
Existing workaround pattern
`paritytech/playground-cli` already mirrors this pattern in `src/utils/deploy/playground.ts` for the metadata upload — builds a dedicated Bulletin client with a 300s heartbeat instead of going through the shared (now host-only) chain client. That pattern works but each consumer has to reinvent it.
What would unblock CI-side callers
Either:
Option 1 is preferred — fewer foot-guns, fewer per-consumer copies of the chain-client config.
Per the playground.dot v0.12 spec
The Summit devnet (and Paseo Next v2 today) is the active V1 network — this gap will hit any project that needs to refresh registry metadata, run E2E publish flows from a Node test harness, or do post-deploy verification from CI.