8000 Fix multisig when the proxy pallet is not available by MOZGIII · Pull Request #11435 · polkadot-js/apps · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fix multisig when the proxy pallet is not available #11435

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

MOZGIII
Copy link
Contributor
@MOZGIII MOZGIII commented Mar 28, 2025

Fixes #11434.

@ap211unitech
Copy link
Member

I would encourage using isFunction(api.tx.proxy) :)

@MOZGIII
Copy link
Contributor Author
MOZGIII commented Mar 28, 2025

I would encourage using isFunction(api.tx.proxy) :)

This is reasonable.

Note though I had to change the check from api.tx.proxy to api.tx.proxy?.proxy - and that .? is a non-trivial thing cause you have to know to add it, as it doesn't follow from the type-system automatically.

I suggest adding | undefied to api.tx.proxy type to make the types actually true to life.


To elaborate more practially: isFunction(api.tx.proxy) is false because api.tx.proxy is not a function actually even when it's defined. So you do either api.tx.proxy !=== undefiend or isFunction(api.tx.proxy?.proxy) - which is better, as there may be other proxy pallet on the chain with a different API that is expected by the code here - for instance without a compatible proxy call.

@ap211unitech
Copy link
Member

that's fine :)

@TarikGul
Copy link
Member

Note though I had to change the check from api.tx.proxy to api.tx.proxy?.proxy - and that .? is a non-trivial thing cause you have to know to add it, as it doesn't follow from the type-system automatically.

I suggest adding | undefied to api.tx.proxy type to make the types actually true to life.

Not really possible atm. The static type generation is for substrate, polkadot, and kusama, having static types for each chain would be too much overhead. This is one of the trade offs with apps supporting any substrate based chain.

@MOZGIII
Copy link
Contributor Author
MOZGIII commented Mar 29, 2025

The static type generation is for substrate, polkadot, and kusama, having static types for each chain would be too much overhead.

I'm not suggesting that though - just making the existing generated types properly describe the world. Supporting any chain means you actually must check for those pallets to conform to the expected API, to a degree at least, before attempting to use them. In fact, the apps already do it.
So, yes, polkadot and kusama do have the proxy pallet always. But you still have to write the code as if they might not have to support all the other chains. I think making the places where the checks are needed visible as the type level would be a simple fix.

So, you only need one set of types really, or maybe two - but still they'd come not from the chains you want to support, but from the particular subsets of APIs you require to implement a particular functionality, i.e. what you actually depend on.

That would be a dream. Yet, in practice, you'd likely still want to codegen types based on some well-known chains capabilities - like Polkadot and Kusama - simply to avoid manually authoring the API declarations (which can actually be automated with a new and different codegen - i.e. say we have a command that would generate the types only for a particular pallet - but alas...). Even with all this said! Even when working with Polkadot chain and Polkadot-specific type codegen. A pallet can still be missing - i.e. be gone from the runtime in the next version - but the codegen just doesn't allow for that possibility. You have to actually check for the pallet to be available at every time.

This seems more like the polkadot-api issue than the apps issue really. It would be great if we had something like this:

const api: Api<..., never> = new Api(...);

const _ = api.tx.proxy.proxy(...); // causes a type error at `api.tx.proxy`: invoking method an `undefined`

const hasProxy: boolean = api.check({ pallet: "proxy" });

const verifiedApi: Api<..., "proxy"> = api.assert({ pallet: "proxy" }); // `<Pallet>(what: { pallet: Pallet }) => asserts this is Api<..., Pallet>` - throw is the `pallet` is not available, is it is correct the `api` type to mark `proxy` as available

const _ = verifiedApi.tx.proxy.proxy(...); // works

Would also be nice to adjust the runtime error at the api.tx.<pallet>.<method> position when the pallet is undefined to day something more explicit about the situation. This is completely irrelevant to the types - but just something to improve the DX and UX for errors. Should also be done at the API level.

@MOZGIII
Copy link
Contributor Author
MOZGIII commented Mar 29, 2025

Also, merge? Any more work to do here?

@ap211unitech ap211unitech merged commit 9b0b98a into polkadot-js:master Mar 31, 2025
5 checks passed
@polkadot-js-bot
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@polkadot-js polkadot-js locked as resolved and limited conversation to collaborators Apr 2, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Unable to submit a multisig transaction on a chain without proxy pallet
4 participants
0