Swagger-API/Custom Smart Contract – Issues with return-data (tuples) of GET-(FF = /POST/query-)functions

[Rabax55]

trafficstars

I'm filing this here, as it's somehow cross-package (Swagger-Api, evm-/ethconnect, firefly-signer). Please relocate as you see fit (probably firefly-signer)...

FireFly - Issue-/Bug-Report

** FireFly-version *** (1) "1.1.2" w/ ethconnect (2) "1.2.0" w/ evmconnect,

** Current behavior: ** The Swagger-Api fails to return tuples of state variables, requested by contract GETter-functions. The RLP-decoding of the data to return fails/is incomplete.

** Expected behavior: ** Return correctly decoded Tuple-data in FF-Swagger Json-Response

** Steps to reproduce: **

1. For (1) -ethconnect: Create a new FF-stack with --blockchain-connector ethconnect (2) -evmconnect: Create a new FF-stack with --blockchain-connector evmconnect

2. For both: deploy the attached SmaCo "DynStructArraysAndAbiTuples.sol" on FF, define contract interface/ABI, register API (via Sandbox...). The contracts Constructor will create some data for it's state-variables DynStructArraysAndAbiTuples.sol.txt ...

3. As reference, deploy the said SmaCo with Remix Desktop-IDE (i used v.0.30.1), and connect it to the geth-node of the respective FF-stack: Remix-IDE-> "Environment", -> select 'External HTTP-Provider'-> with -> "External HTTP Provider Endpoint" = -> 'http://127.0.0.1:5100'

4. Test the following SmaCo-functions (POST/query-endpoints in the FF-Swagger-Interface)

   • getDatingsLength
   • getAllDatings
   • getAllDatingEfforts
   • getDatingByAttempt
   • getAliceEffortByValue

5. Do the same tests in the Remix-IDE, for comparison and reference.

6. See the differences/errors, as documented as well in the attached pdf-document "FF-Tuples-AbiRlp-Decode-Tests.pdf"

FF-Tuples-AbiRlp-Decode-Tests.pdf

** Related code: ** The error-messages 'FF23023'(MsgReturnDataInvalid) from firefly-evmconnect, 'FF22046'(MsgABIArrayCountTooLarge) from firefly-signer

** Other information: ** Reference-tested as well with 'https://github.com/esaulpaugh/headlong-cli' + '~/headlong', a library aiming to be just 'strict' in RLP-en-/decoding. See it's (correct) results in the attached pdf-document.

[nguyer]

Thanks for reporting this @Rabax55! I will attempt to reproduce it and figure out what's going on here when I get some cycles.

[Rabax55]

Hi @nguyer, is there any chance this getting corrected? There was a fix for a RLP-problem - https://github.com/hyperledger/firefly/issues/1323 - that looked similar. Could you please crosscheck, whether my problems are solved w/ this fix, and if not, add the correction for those? There is a complete test-case included here - pls use. These kind of bug(s) just invalidate a whole bunch of Solidity-standards to be used, see?

[nguyer]

Hey @Rabax55 thanks for following up on this. Yes, there have been a number of RLP encoding/decoding fixes that have gone into the FireFly signer library lately. This issue sounds similar to some that were being worked on. If you have an environment that you can re-test this issue in, I think you should be able to use this evmconnect image in your docker-compose.override.yml file, which has the latest fixes in it: https://github.com/hyperledger/firefly-evmconnect/pkgs/container/firefly-evmconnect/98303084?tag=v1.2.12-20230602-55