bug: `eth_getTransactionCount(pending)` ignores nonce gaps between `latest` and the first TX in the pool

[matthew1001]

See Discord thread https://discord.com/channels/905194001349627914/1445364731123728484/1445368389005606923

Steps to Reproduce

1. Submit some transactions which are mined into blocks (e.g. eth_getTransactionCount(latest) now returns 10)
2. Submit a new transaction at a future nonce e.g. eth_sendRawTransaction(nonce = 15), which are not yet mined into blocks because of the nonce gap.
3. Call eth_getTransactionCount(pending). It returns 16, not 10

The caller has no way to determine the correct nonce to use to fill the TX pool nonce gap

Expected behavior:

In the above scenario, eth_getTransactionCount(pending) ought to return 10 so the application can determine the next nonce that will start filling the nonce gap

Actual behavior:

As described above, the nonce gap for the sender in the mempool is returned from the first TX in the mempool onwards. In the example above this returns nonce 16.

Frequency:

100% of the time. It's arguably behaving as designed at present. We're raising this issue to determine if the behaviour should be changed.

[jframe]

@fab-10 Any insight on this? Are we already doing the right thing or should make some changes?

[fab-10]

Actually, unless there is a well defined spec, this could be an acceptable behavior, since I expect that a sender has sent all the txs in sequence without gaps, and the txpool is generally best effort and could create gaps in the sequence, but from the user point of view it should continue from 16 and assume that any of the nonce between eth_getTransactionCount(latest) and eth_getTransactionCount(pending) is missing and resent them is not included in a block as expected.

What other clients are doing in such case?

If the user want to have a precise status of his pending txs, then https://besu.hyperledger.org/public-networks/reference/api#txpool_besupendingtransactions could be useful.