Looks like the transaction payment runtime api uses its own RuntimeDispatchInfo when decoding the result of a query_info. Very similar to https://github.com/paritytech/substrate/pull/6792, this results in using the native RuntimeDispatchInfo all the time. When there was a change on this struct, on a runtime upgrade, (in our case, the weight field change: u32 -> 64), it would result in the api breaking.
@alexsednz can you look to see if my PR solves what you are describing?
@shawntabrizi in my test, the PR hasn't quite solved the issue. Is it possible that it would only work from now on? Or I should be able to query old payment info after updating to your PR?
Hmm, can you go into more details about exactly how you are testing?
My assumption was you have Wasm Runtime u32 Weights, and Native Runtime u64 Weights.
You have not yet upgraded your wasm runtime yet, but all your API calls are failing because it is using the u64 weights defined by native. Is that right?
@shawntabrizi Your account of the issue is quite correct. I left a comment on your PR that may suggest what is still needed.
@shawntabrizi in my test, the PR hasn't quite solved the issue. Is it possible that it would only work from now on? Or I should be able to query old payment info after updating to your PR?
Hey, so you currently not being able to call the transaction payment api for old blocks that still used u32 as Weight? Is that correct?
@bkchr Yes, it's correct.
@alexsednz do you already have a runtime upgrade that is using u64 as Weight?
@bkchr Yes. The problem happens when querying payment info of older extrinsics. It could be a silent wrong decoding issue if the byte used for DispatchClass had had a value within the range of the enum.
In case it helps with understanding the issue, here is our temporary workaround for the problem: https://github.com/plugblockchain/plug-blockchain/commit/cb0944ecb3330cde15c95edf32e711c83f11ed64
@bkchr Yes. The problem happens when querying payment info of older extrinsics. It could be a silent wrong decoding issue if the byte used for DispatchClass had had a value within the range of the enum.
This is bad and prevents any easy solution from our side! Sorry. Otherwise we could have bumped the runtime api version and you would have been able to detect this. For now, I would propose that you either use your workaround or better, workaround this by looking at the block number. You probably know when this upgrade happened and everything before this block number would need to use Weight == u32.
@alexsednz should we close this?
Please reopen if there are still any open questions.