-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Validate contract method return type against ABI #2372
Comments
Note that for #1891 (which I still think is an important issue) incorrect input types can arguably be blamed on the contract consumer as he has control over it. The return type however is controlled by the contract itself, thus I'd argue more important to fix on the chain side. |
In fact, |
Is this described somewhere? Because if not, we better do so as the far majority of ABI consumers will not know this mapping. |
This has not been described. But yes, it should have a document. |
Then the developer must know which NeoVM type corresponds to the C# type, it's so unfriendly. |
These types doesn't match 1x1, correct? I mean, when I got a response from the RPC server with the "ByteString" type it could be many different C# types such as a String, UInt160 and others. Isn't this a problem? For instance, to parse an Array that contains multiple "ByteString" values I would not be able to know which of the values are UInt160 and which are Strings. |
Summary or problem description
Take this contract
which has this manifest
As a contract consumer I expect that I can rely on the interface described by the ABI. Therefore, calling
test_func
is expected to return aboolean
, but in this particular case it returns an integer. (The root cause can be attributed to an incorrect NEF pushing an Integer stackitem instead of a boolean stackitem, but that's not the discussion here.)In this case as a contract consumer I would thus expect a
FAULT
engine state instead of aHALT
with an incorrect result.Historically these kind of issues have occurred and caused trackers and wallets to stop functioning until updated. iirc one such case was an updated Switcheo nep5 token (NEO2) that started returning
Integer
types instead of the expected bytearray. The ABI is there to help prevent this, but currently it doesn't do so.Do you have any solution you want to propose?
Validate the return type against the
returnType
described in the ABI for the method and raise an exception if it deviates.Strongly related to #1891
Neo Version
Where in the software does this update applies to?
The text was updated successfully, but these errors were encountered: