-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Fix multisig when the proxy pallet is not available #11435
Conversation
I would encourage using |
This is reasonable. Note though I had to change the check from I suggest adding To elaborate more practially: |
that's fine :) |
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. |
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, 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 |
Also, merge? Any more work to do here? |
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. |
Fixes #11434.