Incorrect handling of revert flag in pallet-contracts query

[TorstenStueber]

• I'm submitting a ...

  • Bug report
  • Feature request
  • Support request
  • Other

• What is the current behavior and expected behavior?

  When executing a query to pallet-contracts (e.g., new ContractPromise(api, ..., ...).query(...)), then the RPC call will return a value of type ContractExecResult (as defined here). This value is correctly scale decoded and will then be processed at this part of the code. Here result is the actual payload of the return value and will be of type ContractExecResultResult.

  If the query to the contract reverts, then the result will not be an Error but actually an Ok with internal value of type ContractExecResultOk whose flag entry is set to 1, which is represents that the bitflag isRevert is true.

  In this case the data entry of ContractExecResultOk is not supposed to be interpreted to be of the actual return type of the query message sent to the contract, instead it is meant to be interpreted as a type selector of a type referenced by the contract metadata declaration lang_error followed by the value of that type.

  This is currently wrongly implemented as the value in data is decoded using the return value of the contract message independent and a possible REVERT flag is ignored.

• What is the motivation for changing the behavior?
  Correctly interpret messages that revert. This is particularly important for automated tests where some contracts are expected to revert and where the contained data value needs to be compared to an expected data value.

• Please tell us about your environment:

  • Version: current master branch that I link to in my explanation above (commit d8136a8)
  • Environment: not revelant
  • Language: not revelant

[xermicus]

I'm not too familiar with polkadot-js, but I'd assume that this is not going to work for Solang contracts. By my understaing, you're assuming that the execution output type is always the same, regardless whether the contract did revert or not right? Solidity contracts unfortunately can't really do this; Solidity doesn't know about Result and even if it would, the output could be empty (where Solidity doesn't know about the Option type neither), or the output could be of a type that isn't present in the metadata (due to Solidity bubbling up uncaught errors).

[TorstenStueber]

Seems that I incorrectly assumed that this is already standardized semantics of the contract metadata. But it is not and still up to debate.

For that reason I will close this ticket for now.

[polkadot-js-bot]

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.