add gas conditional if simple transaction

[luu-alex]

Description

#7021
There seems to be a bug when using sendTransaction with no gas property in the rpc method eth_call in checkRevertBeforeSending. Testing with both metamask and an infura provider, with a simple transaction (with no data or input so no contract call)
eth_call will revert and say there is insufficient funds when there should be easily enough funds to cover the gas and value.
The transaction looks like

const tx = {
        to: 0,
        value:1,
        from: accounts[0].address,
    }

InvalidResponseError: Returned error: err: insufficient funds for gas * price + value: address 0xBe1320eA9Fd1b34C0cf664eFbb29CF2dBD3cC81b have 100000000000000000 want 2859580732500000001 (supplied gas 50000000)
    at Web3RequestManager._processJsonRpcResponse (/Users/alexluu/practice/v4web3js/node_modules/web3/node_modules/web3-core/lib/commonjs/web3_request_manager.js:258:23)
    at Web3RequestManager.<anonymous> (/Users/alexluu/practice/v4web3js/node_modules/web3/node_modules/web3-core/lib/commonjs/web3_request_manager.js:156:29)
    at Generator.next (<anonymous>)
    at fulfilled (/Users/alexluu/practice/v4web3js/node_modules/web3/node_modules/web3-core/lib/commonjs/web3_request_manager.js:21:58)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  innerError: {
    code: -32000,
    message: 'err: insufficient funds for gas * price + value: address 0xBe1320eA9Fd1b34C0cf664eFbb29CF2dBD3cC81b have 100000000000000000 want 2859580732500000001 (supplied gas 50000000)'

Solution

Within checkRevertBeforeSending, A simple fix to this is to check if the transaction does not have data set we explicitly set the gas to 21000

Please include a summary of the changes and be sure to follow our Contribution Guidelines.

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)

Checklist:

• I have selected the correct base branch.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• Any dependent changes have been merged and published in downstream modules.
• I ran npm run lint with success and extended the tests and types if necessary.
• I ran npm run test:unit with success.
• I ran npm run test:coverage and my test cases cover all the lines and branches of the added code.
• I ran npm run build and tested dist/web3.min.js in a browser.
• I have tested my code on the live network.
• I have checked the Deploy Preview and it looks correct.
• I have updated the CHANGELOG.md file in the root folder.
• I have linked Issue(s) with this PR in "Linked Issues" menu.

[github-actions]

Bundle Stats

Hey there, this message comes from a GitHub action that helps you and reviewers to understand how these changes affect the size of this project's bundle.

As this PR is updated, I'll keep you updated on how the bundle size is impacted.

Total

Files count	Total bundle size	% Changed
10	624.38 kB → 624.51 kB (+133 B)	+0.02%

Changeset

File	Δ	Size
../web3-eth/lib/commonjs/utils/send_tx_helper.js	📈 +418 B (+4.74%)	8.6 kB → 9.01 kB

View detailed bundle breakdown

Added

No assets were added

Removed

No assets were removed

Bigger

Asset	File Size	% Changed
web3.min.js	605.08 kB → 605.21 kB (+133 B)	+0.02%

Smaller

No assets were smaller

Unchanged

Asset	File Size	% Changed
../lib/commonjs/index.d.ts	8.69 kB	0%
../lib/commonjs/accounts.d.ts	3.89 kB	0%
../lib/commonjs/types.d.ts	2.67 kB	0%
../lib/commonjs/web3.d.ts	1.35 kB	0%
../lib/commonjs/web3_eip6963.d.ts	1.2 kB	0%
../lib/commonjs/abi.d.ts	999 B	0%
../lib/commonjs/eth.exports.d.ts	280 B	0%
../lib/commonjs/providers.exports.d.ts	183 B	0%
../lib/commonjs/version.d.ts	60 B	0%

[github-actions]

Benchmark

Benchmark suite	Current: 37455eb	Previous: 2f73aa5	Ratio
processingTx	9318 ops/sec (±3.60%)	9204 ops/sec (±3.98%)	0.99
processingContractDeploy	38185 ops/sec (±7.60%)	38039 ops/sec (±7.10%)	1.00
processingContractMethodSend	20016 ops/sec (±6.64%)	19205 ops/sec (±6.35%)	0.96
processingContractMethodCall	40554 ops/sec (±5.76%)	40094 ops/sec (±5.17%)	0.99
abiEncode	45972 ops/sec (±6.71%)	43919 ops/sec (±6.46%)	0.96
abiDecode	30557 ops/sec (±7.62%)	29754 ops/sec (±7.79%)	0.97
sign	1582 ops/sec (±3.25%)	1568 ops/sec (±0.52%)	0.99
verify	376 ops/sec (±0.52%)	372 ops/sec (±0.68%)	0.99

This comment was automatically generated by workflow using github-action-benchmark.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.98%. Comparing base (866469d) to head (37455eb).
Report is 1 commits behind head on 4.x.

Additional details and impacted files

@@           Coverage Diff           @@
##              4.x    #7043   +/-   ##
=======================================
  Coverage   91.97%   91.98%           
=======================================
  Files         215      215           
  Lines        8291     8294    +3     
  Branches     2277     2278    +1     
=======================================
+ Hits         7626     7629    +3     
  Misses        665      665           

Flag	Coverage Δ
UnitTests	91.98% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
web3	∅ <ø> (∅)
web3-core	∅ <ø> (∅)
web3-errors	∅ <ø> (∅)
web3-eth	∅ <ø> (∅)
web3-eth-abi	∅ <ø> (∅)
web3-eth-accounts	∅ <ø> (∅)
web3-eth-contract	∅ <ø> (∅)
web3-eth-ens	∅ <ø> (∅)
web3-eth-iban	∅ <ø> (∅)
web3-eth-personal	∅ <ø> (∅)
web3-net	∅ <ø> (∅)
web3-providers-http	∅ <ø> (∅)
web3-providers-ipc	∅ <ø> (∅)
web3-providers-ws	∅ <ø> (∅)
web3-rpc-methods	∅ <ø> (∅)
web3-utils	∅ <ø> (∅)
web3-validator	∅ <ø> (∅)

[jdevcs]

when data is populated, is gas limit always populated in that case?

[jdevcs]

and its only missing in case of value transfers eth_calls only?

[jdevcs]

additionally, if tx has gas limit only for eth_call rpc( for revert check) and not in actual Tx that will be sent after it,
eth_call may pass while actual Tx may fail in some cases, as both will differ, so I think gas limit should be applied in all cases

[luu-alex]

eth_call with no data and no gas will fail from provider, but send_transaction gas will be filled automatically. i belive this is just a weird edge case, and with our tests passing i dont believe this will be an issue.