Kintsugi metadata not updated?

[mafux777]

I am trying to use this package to do stuff programmatically in python. Reading from storage works fine, so I think I have got the basics correct.

When trying to do a transfer like this,

keypair = Keypair.create_from_mnemonic(new_mnemo, ss58_format=2092, language_code=MnemonicLanguageCode.ITALIAN)
my_address = keypair.ss58_address
a=get_account_balances(my_address, 'KINT')


call = kint_substrate.compose_call(
    call_module='Tokens',
    call_function='transfer',
    call_params={
        'dest': 'a3cFU1biFvmBCup9SBvqihpvqVmwCtLsT1mK2dzqwWC94AjJw',
        'currency_id': {'Token': 'KINT'},
        'amount': a['free']//2,
    }
)

payment_info = kint_substrate.get_payment_info(call=call, keypair=keypair)

I get this:

substrateinterface.exceptions.SubstrateRequestException: {'code': 1, 'message': 'Unable to query dispatch info.', 'data': 'Execution failed: Execution aborted due to trap: wasm trap: wasm `unreachable` instruction executed\nWASM backtrace:\n\n    0: 0x34f44a - <unknown>!rust_begin_unwind\n    1: 0x1190c - <unknown>!core::panicking::panic_fmt::hce09957bf3e88e08\n    2: 0x1fc0f6 - <unknown>!TransactionPaymentApi_query_info\n'}

[mafux777]

The Interlay team tell me this may be related: https://github.com/paritytech/subxt/issues/505#issuecomment-1091677922

[arjanz]

Yes it seems like a runtime specific issue (panic in the runtime WASM), it also happens when I post the same RPC request payment.queryInfo on PolkadotJS with that extrinsic. Maybe signing of that kind of extrinsic is not allowed (yet)? I don't have much experience with that specific parachain implementation unfortunately.

[mafux777]

Hi Arjan, I am not part of the Interlay team, but maybe I have a way of organising a meeting between you and one of their developers to get to the bottom of this. My hope is that it turns out to be a small issue that can be resolved there and then. Could you come to the Interlay discord to arrange? My handle there is mafux777#4195

[RobinDavid]

Hi @arjanz ! I encountered the same problem. I initially thought it was linked to the signature with SignedExtensions but after in-depth investigation. It seems py-substrate-interface uses the right ones in the right order. After trying to understand scale-codec internal handling of types I am running out of ideas why extrinsic are rejected.

I now think the problem is similar to 258 and we are probably lacking some types to get valid extrinsic calls. I am not as familiar as you with the code, but I'd be eager to help on that (as your library really deserve some love and to be used more ^^').

Regards,

[kazakovdev]

Hello! Did you find a solution? I got a similar problem while developing my software on Interlay parachain. The same error occurs when trying to sign another extrinsic (interacting with XCM):

call = self.polkadot_substrate.compose_call(
            call_module='XTokens',
            call_function='transfer',
            call_params={})

extrinsic = self.polkadot_substrate.create_signed_extrinsic(call=call, keypair=self.keypair)

This code raise the error: substrateinterface.exceptions.SubstrateRequestException: {'code': 1002, 'message': 'Verification Error: Runtime error: Execution failed: Execution aborted due to trap: wasm trap: wasm unreachable instruction executed\nWASM

Connector looks like this:

polkadot_substrate = SubstrateInterface(
            url = '...',
            ss58_format=2,
            type_registry_preset='polkadot'
        )
        keypair = Keypair.create_from_uri(SEED)

[RobinDavid]

Unfortunately not. I spent some time tracking the origin but gave up. I think it would need @arjanz help.

[arjanz]

Unfortunately not. I spent some time tracking the origin but gave up. I think it would need @arjanz help.

I'm at sub0 atm so my time is a bit limited, but what you could try is to compare the extrinsic bytes ( str(extrinsic.data) ) generated with py-substrate-interface against the same extrinsic generated with PolkadotJS to rule out any SCALE encoding difference.

[kazakovdev]

Unfortunately not. I spent some time tracking the origin but gave up. I think it would need @arjanz help.

I'm at sub0 atm so my time is a bit limited, but what you could try is to compare the extrinsic bytes ( str(extrinsic.data) ) generated with py-substrate-interface against the same extrinsic generated with PolkadotJS to rule out any SCALE encoding difference.

Thank you for your time! Just checked. The bytes in PolkadotJS and in call.data are identical. At the same time, when sending through the JS extension, all is successful PS This call works in other parachains (tried Acala for experiment, they have same extrinsic)

[gregdhill]

We were able to submit a call using this solution: https://github.com/polkascan/py-substrate-interface/issues/315#issuecomment-1413780522

[arjanz]

I just released a new version that has auto-detection for Address and ExtrinsicSignature types stored in the metadata, so manually specifying the Address type should not be necessary anymore: https://github.com/polkascan/py-substrate-interface/releases/tag/v1.5.0

[kazakovdev]

I confirm the issue I encountered: substrateinterface.exceptions.SubstrateRequestException: {'code': 1002, 'message': 'Verification Error: Runtime error: Execution failed: Execution aborted due to trap: wasm trap: wasm unreachable instruction executed\nWASM is resolved with the latest release. Thank you @arjanz