firefly icon indicating copy to clipboard operation
firefly copied to clipboard

getIds { output: null }

Open agiratech-vignesh-m opened this issue 1 year ago • 2 comments

I suspect there is a bug in the FireFly signer ABI encoding. This contract demonstrates the issue: https://mumbai.polygonscan.com/address/0xc0bc785b2c5494820B63c7108547b4652b9742aD#code

Steps to reproduce:

Create a new FireFly stack (using default settings with a local blockchain node is fine) Create a contract interface / API with the contract listed above Call the POST /invoke/createCoupon endpoint with the following payload:

{ "input": { "_end": "1234", "_id": "2345", "_ipfsUrl": "3456", "_start": "4567" } }

Call the POST /query/allCouponIds with an empty JSON object as the request body Response: We will get an response as : getIds { output: null }, even i tried with other functions receiving the same error. On Polygonscan I see a valid response from this method.

agiratech-vignesh-m avatar May 11 '23 10:05 agiratech-vignesh-m

Received the same issue and reported here - https://github.com/hyperledger/firefly/issues/1303#issuecomment-1552962333

joshtharakan avatar May 19 '23 02:05 joshtharakan

I've taken a look at this one and figured out the problem

When a contract annotates the returning values in the tuple we decode correctly and construct a map with the keys being the annotated name in this case map[string]interface{} where

{
  "allCouponIds": [2345]
}

Yet the transaction manager is expecting an output field and the result nested under it. If it's not there it cannot unmarshall/decode it and the result is null!

{
 "output": {
   "allCouponIds": ....
 }
}

The way we add this output nesting here https://github.com/hyperledger/firefly-signer/blob/038e29f0aeb724ab5b716a772ff839e2419133d2/pkg/abi/outputserialization.go#L226 if the children component doesn't have a key name we set it to output and serialise everything under it but we do have a key name for each children so we never add this output nesting. A possible solution would be to use the TypeComponent key names instead of the TupleChildren key names but appreciate any other ideas

EnriqueL8 avatar Jun 06 '23 11:06 EnriqueL8