This might be sufficient for applications using only the number or for test cases, but not for applications relying on the counter, like hardhat-ignition does.
For example hardhat-ignition fails to interact with vechain networks, because it detects pending transactions that do not exist.
I suggest to:
Either return 0 at all times or return the current block number
and add Transaction Pool and filter for the request address, to return a meaningful number in the pending request
As reference, here are requests within ignition that result in invalid conditions:
Description
When accessing
eth_getTransactionCount
on the RPC Mapper, there is a random number returned at all times.https://github.com/vechain/vechain-sdk-js/blob/630d4028096de84d82ea2176985c086cfd9acb03/packages/network/src/provider/utils/rpc-mapper/methods-map/methods/eth_getTransactionCount/eth_getTransactionCount.ts#L46
This might be sufficient for applications using only the number or for test cases, but not for applications relying on the counter, like
hardhat-ignition
does.For example hardhat-ignition fails to interact with vechain networks, because it detects pending transactions that do not exist.
I suggest to:
0
at all times or return the current block numberAs reference, here are requests within ignition that result in invalid conditions:
https://github.com/NomicFoundation/hardhat-ignition/blob/development/packages/core/src/internal/execution/nonce-management/get-nonce-sync-messages.ts#L89-L112
Reproduction URL
No response
Reproduction steps
Returns a value, even if there is nothing pending:
Screenshots
Logs
No response
OS
No response