First, the returnValue
looks correct, it is indeed 42
4> {_, X} = aeser_api_encoder:decode(<<"cb_VNLOFXc=">>).
{contract_bytearray,<<"T">>}
5> aeb_fate_encoding:deserialize(X).
42
The problem is that you are using the legacy decoding endpoint /decode-data
it only works for AEVM results. To decode the result of a contract call it is better to use /decode-call-result
- it takes slightly different parameters:
curl -H "Content-Type: application/json" -d "{\"source\":\"$contract\",\"function\":\"main\", \"call-result\":\"ok\", \"call-value\":\"cb_VNLOFXc=\",\"options\":{\"backend\":\"fate\"}}" -X POST http://localhost:3080/decode-call-result
42
Finally, about getting a returnType
that is Base64Check encoded (cb_...
). It sounds weird, the returnType
should be either ok
, revert
, or error
as you mention. Which HTTP-endpoint did give you that? Could you post the full response?
1 Like
regarding the returnType -> we are mapping the response into our own objects. seems like we got an issue there. response looks good:
{"results":[{"call_obj":{"caller_id":"ak_twR4h7dEcUtc2iSEDv8kB7UFJJDGiEDQCXr85C3fYF8FdVdyo","caller_nonce":5,"contract_id":"ct_S1WcdNQf5dqVcnC6pc9kwMNVz84s91ZMeUZfYjzHgreBznzuA","gas_price":1000000000,"gas_used":11,"height":139,"log":[],"return_type":"ok","return_value":"cb_VNLOFXc="},"result":"ok","type":"contract_call"}]}
I am just adding the /decode-call-result
endpoint to our compiler-service. I noticed, that in the swagger-definition of the compiler the SophiaCallResult
-Definition has no property. I guess that needs to be added, right? currently it is empty
SophiaCallResult: {}
SophiaCallResultInput:
example:
call-result: call-result
call-value: call-value
function: function
options:
backend: fate
file_system: '{}'
src_file: src_file
source: source
properties:
call-result:
description: Call result type (ok | revert | error)
type: string
call-value:
description: Call result value (ABI encoded data or error string)
type: string
function:
description: Name of the called function
type: string
options:
$ref: '#/definitions/CompileOpts'
source:
description: (Possibly partial) Sophia contract code/interface
type: string
required:
- call-result
- call-value
- function
- source
edit
-
@hanssv.chain can you please change the response in the compiler regarding that endpoint? doesn’t seem to be a valid json. it is just returning the value 42
Hmm, last time I checked 42
is perfectly valid as a JSON value?
If I remember correctly, the reason for not specifying SophiaCallResult
was that Swagger didn’t like what I tried to say… So in the end I went with {}
which supposedly means “anything” in Swagger lingo. Improvement suggestions are welcome.
1 Like
again my mistake. haven’t used json with the context of a single value so fair.
still the SophiaCallResult
should probably be defined in another way. currently when generating java classes from the swagger definition there is absolutely no chance to deserialize the response because the generated class has no attribute.
to fix the problem for us I changed to swagger-definition as follows:
/decode-call-result:
post:
consumes:
- application/json
description: Decode the result of contract call
operationId: DecodeCallResult
parameters:
- description: Binary data in Sophia ABI format
in: body
name: body
required: true
schema:
$ref: '#/definitions/SophiaCallResultInput'
produces:
- application/json
responses:
'200':
description: Json encoded data
schema:
oneOf:
- type: string
- type: integer
- type: number
- type: boolean
- type: array
'400':
description: Invalid data
schema:
$ref: '#/definitions/CompilerErrors'
we now totally ignore the SophiaCallResult
definition. I don’t know whether this would cover all response-values.
the response could also contain maps, right? for the moment I only tested the change for the sample function that returns an integer.
It is using the ACI generator, and its JSON encoder. It returns a JSON representation of the Sophia value. If I remember correctly Sophia-tuples are mapped to JSON-array, numbers are numbers, booleans are booleans, strings are strings, Sophia-records become JSON-objects, constructors also become JSON-objects, and Sophia-maps will become an array of pairs (arrays with length2) in JSON.
(42, true, "Hello", ()) => [42, true, "Hello", []]
(One(12, 18), Two) => [{"One": [12, 18]}, {"Two": []}]
{x = 43, y = "Foo", z = { [1] = 2 }} => {"x": 43, "y": "Foo", "z": [[1, 2]]}
we will test whether my “workaround” will be able to cover decoding these response-values. thanks
As far as I can read the Swagger documentation what you’ve written more or less means {}
so let’s see what happens.