FF23023: EVM return data invalid: FF22047: Insufficient bytes to read string value

[nguyer]

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:

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

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

4. Call the POST /query/viewAllCreatedTokens endpoint with an empty JSON object as the request body

Response:

{
  "error": "FF10111: Error from ethereum connector: FF23023: EVM return data invalid: FF22047: Insufficient bytes to read string value [tup,i:0,b:0][dyn,i:0,b:64][tup,i:1,b:128]"
}

On Polygonscan I see a valid response from this method should look like:

[[1,QmdbaSQbGU6Wo9i5LyWWVLuU8g6WrYpWh2K4Li4QuuE8Fr,1683555160,1683554160]]

[nguyer]

evmconnect.log
Here's a full evmconnect log with the error

[EnriqueL8]

So the query to get the tokens which return a tuple of type (uint256, string, uint256, uint256) is encoded as such

Blocks                                                           Index.  Value
0000000000000000000000000000000000000000000000000000000000000020 0       32 // offset for the list of tuples  
0000000000000000000000000000000000000000000000000000000000000001 32      1  // Number of tuples in the list (length)
0000000000000000000000000000000000000000000000000000000000000020 64      32 // Start position for the respective tuples
000000000000000000000000000000000000000000000000000000000000007b 96      123 // ID I gave the coupon 
0000000000000000000000000000000000000000000000000000000000000080 128     128 // Offset to where the UTF8 string starts (the length of it first)
000000000000000000000000000000000000000000000000000000000031079d 160     3213213 // _start of coupon I gave
0000000000000000000000000000000000000000000000000000000000005e4d 192     24141 // _end of coupon I gave
000000000000000000000000000000000000000000000000000000000000000b 224     11 // Length in bytes of the string that comes next
7468697369736d7975726c000000000000000000000000000000000000000000 256     // String starts here 128 + 128 

The bug is that when we add up the offset of the string to the current position we are passed there wrong parameters in. We want to add the Head Start (in the case the start of the tuple) to the data offset for the string. Unfortunately, we weren't passing the right head start parameter to the function where we traverse the bytes. So the error that occurs we try to decode a int as an string!

This is fixed as part of hyperledger/firefly-signer#42

There is an additional fix that @peterbroadhurst when he noticed that we were returning the full length of the walkDynamicChildArrayABIBytes to the headBytesRead of decodeABIElement - but actually, only the 32bytes of the headOffset were from the header.. This meant that we were moving the head position by too much when decoding the element of a dynamic array which causes loads of issues.

[joshtharakan]

I have also encountered a similar issue where when I have created FFI & API for a simple straight forward contract
contract - https://github.com/joshtharakan/solidity-template/blob/main/contracts/greeter/Greeter.sol
Steps to reproduce

1. Create a new FireFly stack. (I used besu node)
2. Create a contract interface & API with the Greeter contract listed above
3. Call the POST /invoke/setGreeting endpoint with the following payload:

{
    "input": {
        "_greeting": "bonjour"
    }
}

4. Call the POST /query/greet endpoint with an empty JSON object as the request body

{
  "input": {}
}

Response:

{
    "output": null
}

Apparently, the call towards the API generated against the solidity created getter functions for the public variable greeting works fine

POST /query/greeting

input

{
  "input": {}
}

Response:

{
    "output": "bonjour"
}

I am able to get the proper response when I tried interacting with the node directly with an eth_call and also with ethers.js providing the ABI. I tried with a couple of other contracts as well and all have the same problem.

I am also unable to get any errors reported in evmconnect service.

docker logs scip-local-besu_evmconnect_0 2>&1 | egrep eth_call
[2023-05-18T11:56:42.760Z] DEBUG evmconnect: RPC[000012690] --> eth_call httpreq=iFkO1c7K req=_tVwslnH
[2023-05-18T11:56:42.768Z]  INFO evmconnect: RPC[000012690] <-- eth_call [200] OK (8.06ms) httpreq=iFkO1c7K req=_tVwslnH
[2023-05-18T12:00:51.034Z] DEBUG evmconnect: RPC[000013479] --> eth_call httpreq=xWwHFfg3 req=mF9p5IQk
[2023-05-18T12:00:51.043Z]  INFO evmconnect: RPC[000013479] <-- eth_call [200] OK (8.59ms) httpreq=xWwHFfg3 req=mF9p5IQk
[2023-05-18T12:01:02.588Z] DEBUG evmconnect: RPC[000013516] --> eth_call httpreq=REb2E9Yp req=gtizpjTN
[2023-05-18T12:01:02.596Z]  INFO evmconnect: RPC[000013516] <-- eth_call [200] OK (8.46ms) httpreq=REb2E9Yp req=gtizpjTN
[2023-05-18T12:01:07.424Z] DEBUG evmconnect: RPC[000013533] --> eth_call httpreq=BzXxI3Ce req=DyVGEOuE
[2023-05-18T12:01:07.432Z]  INFO evmconnect: RPC[000013533] <-- eth_call [200] OK (7.88ms) httpreq=BzXxI3Ce req=DyVGEOuE
[2023-05-18T12:02:48.192Z] DEBUG evmconnect: RPC[000013851] --> eth_call httpreq=98pbrWWM req=JLSlyc0B
[2023-05-18T12:02:48.204Z]  INFO evmconnect: RPC[000013851] <-- eth_call [200] OK (11.98ms) httpreq=98pbrWWM req=JLSlyc0B
[2023-05-18T12:07:40.997Z] DEBUG evmconnect: RPC[000014780] --> eth_call httpreq=sriA_acw req=8h1l77Ud
[2023-05-18T12:07:41.005Z]  INFO evmconnect: RPC[000014780] <-- eth_call [200] OK (7.40ms) httpreq=sriA_acw req=8h1l77Ud

[EnriqueL8]

@joshtharakan Merged a PR recently that fixed the above problem #1333 - let me know if you are still hitting the issue