add fillInputData option argument to formatTransaction on call function in rpc_method_wrappers

[moshmage]

Description

The fillInputData option on formatTransaction call that was introduced with this change left eth_call method unchanged. In my case, 4.1.0 + hardhat was unable to call a simple ERC20.name() returning unkown function selector (even if the contract had a fallback).

Adding this argument to the function call when call() is made fixed it on my side.

• (should) Fix Data is missing from methods.myMethod #6355

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

[luu-alex]

Hey there @moshmage . As well I have a pr that addresses different issues related to that change, but i'll merge this branch with mines. Thanks a ton for opening this PR and if there are any other issues you are facing, feel free to open another issue/pr

[luu-alex]

Hey there @moshmage do you have an code snippet you can share of how your using this code? it'll help me out a ton :)

[moshmage]

Hey there @moshmage do you have an code snippet you can share of how your using this code? it'll help me out a ton :)

sure @luu-alex -- head over to https://github.com/moshmage/dappkit/blob/3.x.x/test/models/base-model.spec.ts#L59 (where it fails the test): the await model.contract.methods.name().call() is calling the web3js implementation (.contract.methods = new web3.eth.Contract(abi, address).methods). This will only fail on a hardhat local chain (I tested it against a ganache fork of ethereum and it went smoothly). you can check the contract here https://github.com/moshmage/dappkit/blob/3.x.x/contracts/token/ERC20/ERC20.sol#L41 (excuse the mess, in the process of cleaning up ^^')

You can read how to set-up a dev-env on https://github.com/moshmage/dappkit/blob/3.x.x/how-to/contributing/readme.md

ps: The way I got to the "fill input data was" that I just echoed out the json params that web3js@1.x.x was doing against the current version and noticed that the 1.x.x call had data and input, and not just one - after adding the fillInputData: true to a local-fork of web3js the tests went by smoothly as well.

[luu-alex]

Thanks alot this is really helpful!

We are actually trying to get away from using the default call to be both data and input, we made the default to be only filling input in the eth_call and I think the error you are running into is due to hardhat could only be accepting data.

I'll be adding to the PR so that you can use a flag when creating your contract to include in your method calls to either send data, input or both. Does this solution work for you?

[moshmage]

Thanks alot this is really helpful!

We are actually trying to get away from using the default call to be both data and input, we made the default to be only filling input in the eth_call and I think the error you are running into is due to hardhat could only be accepting data.

I'll be adding to the PR so that you can use a flag when creating your contract to include in your method calls to either send data, input or both. Does this solution work for you?

Being fair to hardhat, the only place where input is documented is on geth execution-apis documentation repo here -- everywhere else, input is not even mentioned (including eth.org oficial docs)

That said, as long as web3js plays ball with hardhat it'll be cool by me;

But I'm afraid that this change will add a "we will deal with any and all edge-cases" precedent and I don't wanna be the cause for it :P

Wouldn't it be better if we go to the handleRevert route and have it on the Web3Config, instead of "per contract" basis -- that way userland can simply turn the option on and be done with it - no need to understand the underlyings of the Contract class ^^

[luu-alex]

I understand, i'm not too sure why the geth documentation and eth official docs are different but we have been trying hard to follow the geth repo as much as possible.

I think your suggestion is great! It will be included as a web3config.