apps
apps copied to clipboard
[encointer] can't decode block if it contains a tx payed with a non-native asset.
See: https://github.com/encointer/encointer-parachain/issues/127
The reason here is that polkadot-js/api does not generate the signed extensions on the fly; the AssetId of the OnChargeAssetTxPayment is hardcoded to Option<Number>, while we have Option<CommunityIdentifier>.
On the client side, I solved this with the following code-block:
const api = await ApiPromise.create({
...options({
types: configOverride.types !== null ? configOverride.types : {}
}),
signedExtensions: {
ChargeAssetTxPayment: {
extrinsic: {
tip: 'Compact<Balance>',
assetId: 'Option<CommunityIdentifier>'
},
payload: {}
}
},
provider: provider
});
As far as I know, I can no longer set custom types in polkadot-js/apps. So how can I get this change there?
At this point the API only supports the default signed extensions and their types. (There is an issue logged to extract custom types, so that will go in at some point in the future)
Do you have an example chain & blockHash to work with? It will help greatly in testing https://github.com/polkadot-js/api/issues/4197 (aka testing inside the apps UI with an adjusted API)
Yes (taken from the linked issue above):
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo.api.encointer.org#/explorer/query/0xfb56d3ad3451d25a213a90c14fffa06cfedd177389f1fa697bc2786de369cf8f
Thanks for tackling this! Do you have an estimate, when you work on this?
No firms plans to look at this. (There may be some work medium-term, most-probably not comprehensive, as time permits)
This issue has been open for 21 days with no activity and is not labelled as an enhancement. It will be closed in 7 days.
I am trying to solve the extrinsic decoding issue by adjusting our config to the following:
const definitions: OverrideBundleDefinition = {
types: [
{
// on all versions
minmax: [0, undefined],
types: {
// ...all types
}
}
],
signedExtensions: {
ChargeAssetTxPayment: {
extrinsic: {
tip: 'Compact<BalanceType>',
assetId: 'Option<CommunityIdentifier>'
},
payload: {}
}
}
};
But I still get the same errors (as in this block):
Unable to retrieve the specified block details. createType(SignedBlock):: Struct: failed on block: {"header":"Header","extrinsics":"Vec<Extrinsic>"}:: Struct: failed on extrinsics: Vec<Extrinsic>:: createType(ExtrinsicV4):: createType(Call):: findMetaCall: Unable to find Call with index [57, 119]/[57,119]
Any advice @jacogr?
The types bundle has a pre-build step, so running yarn build:extra before yarn start ensures that the types for all chains are pulled-in. (This is actually run on CI when a merge is done, hence deployments has this "as-built config".)
However, doing that with the definition you gave above yields the following -
Unable to retrieve the specified block details. createType(SignedBlock):: Struct: failed on block: {"header":"Header","extrinsics":"Vec<Extrinsic>"}:: Struct: failed on extrinsics: Vec<Extrinsic>:: createType(ExtrinsicV4):: createType(ExtrinsicSignatureV4):: decodeU8a: failed at 0x017530716a3977f79df73d0200… on assetId (index 6/6): Option<CommunityIdentifier>:: Expected input with 32 bytes (256 bits), found 12 bytes
So it certainly uses that extension based on the type shown (on the specific block you linked), but something seems off with the type definition as it stands.
Thanks a lot, the pre-build step did the trick!
@jacogr can i also hook this config to the testnet?
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.