Error when performing dryRun (Lima v5.0.0-rc.2)

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 :slight_smile:

As far as I can read the Swagger documentation what you’ve written more or less means {} so let’s see what happens.