GetTransactionCount with "pending" doesn't return the correct count

Bugs
1

Hey,

My wallet address is 0xDb2b015F7Adf402443d1a2bDf309A28B66b1BE22, yesterday I made a transaction with a low Gas price of 0.5 Gwei and that transaction was stuck and not mined for about an hour,

so to fix that, I created another transaction with the same nonce to drop and replace the old stuck tx, and it worked and the transaction was mined correctly.

Right after that, calling getTransactionCount (with "pending" as the block parameter) using the Infura json-rpc API, I keep getting the wrong transaction count for my address (it double counts the replacing transaction and the other transaction), thus using that value for my nonce service creates a nonce gap, making all my future transactions rejected by the network. Also for some reason, Infura keeps counting those failed transactions in the returned value from the RPC call to getTransactionCount.

This behavior is inconsistent with a local geth fullnode running on mainnet, to replicate this bug, try the following call on Infura, and on another fullnode

Using Infura’s json-rpc api:


// using the "pending" block parameter

$ curl https://mainnet.infura.io/v3/YOUR-PROJECT-ID -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params": ["0xDb2b015F7Adf402443d1a2bDf309A28B66b1BE22","pending"],"id":1}'

{"jsonrpc":"2.0","id":1,"result":"0x6a"} //0x6a = 106

​

// Using the "latest" block parameter

$ curl https://mainnet.infura.io/v3/YOUR-PROJECT-ID -X POST -H "Content-Type: application:"eth_getTransactionCount","params": ["0xDb2b015F7Adf402443d1a2bDf309A28B66b1BE22","latest"],"id":1}'

{"jsonrpc":"2.0","id":1,"result":"0x2"}

Using a local geth fullnode (on mainnet):

> eth.getTransactionCount("0xDb2b015F7Adf402443d1a2bDf309A28B66b1BE22", "pending")

2

> eth.getTransactionCount("0xDb2b015F7Adf402443d1a2bDf309A28B66b1BE22", "latest")

2

It seems that there’s some caching layer on Infura’s side that doesn’t correctly handle drop and replace transactions, and any further transactions with a wrong nonce, any idea if that’s a problem from my side somehow?

Thanks

1 Like
2

Thanks for reporting, our team is looking into it. We do have a caching layer on pending transactions and this might be related to that. I’ll post an update here shortly.

3

Hi there @osagga. We were able to reproduce your issue and have disabled our cache while we roll out a fix. Thanks for reporting and apologies for the inconvenience.

1 Like
4

Awesome, thanks for the quick response!

Yeah I can confirm that the API returns the right number now, but that’s probably because the caching is off.

5

Hi @osagga. After digging into the data more, it looks like we did receive dozens of transactions from your address with the nonce ranging from 3 to 96. Were you trying to send a batch of transactions or were you retrying the transaction with a difference nonce to try to get it unstuck? We want to understand what your actions were so we make sure we understand what fix if any is appropriate. Any further details you can share would be great.

6

Hey @egalano,

Sorry for the late reply, but yeah my wallet implementation was a bit spammy and kept increasing the nonce by one and retry posting the same transaction multiple times, but it was just getting rejected by the network since the first nonce it tried after the drop & replace was one more than it should be (because Infura double counted the drop & replace transaction), therefore creating a nonce gap. I was only able to fix it by hard-coding the correct nonce.

I hope that explains what happened, let me know if you have any other questions.

1 Like
7

Got the same issue here.
I did call getTransactionCount(address,‘pending’) twice to get nonce before send two transfer txns with 10 seconds interval.
However i got same nonce, and the two transfer txns all got txn hash.
Anyway to fix this ?

8

Hi @infura1, and welcome to the Infura community!
Doing getTransactionCount(address, 'pending') will give you a hex code of the number of transactions you sent from the address, not the nonce number. There are a couple of ways to go about getting the nonce numbers - you can read up on that in this thread, particularly towards the bottom.

Please let us know if you’re still having issues!

9

Thanks for reply.
I’ve read through the thread, however not much help to my issues.
I just encountered the duplicate nonce issue minutes ago, paste the information here:

  1. I called getTransactionCount(address, ‘pending’) trying to get the next nonce of my address1, got nonce from api: 345. Sent a txn with nonce as 345 got txn hash from api - 0x765be03d81aabec1592f4290f9d8974a4f7a879a443785aee6634414bd6bd90c

  2. 5secs later, called getTransactionCount(address, ‘pending’) again, got nonce from api: 345. Sent a txn with nonce as 345 got txn hash from api - 0xc2333393ebfe728d233f16ebba9e44cad3762e6bad35a0b4faa36f0a7a1a3c92

Any idea why i got same nonce in two calls ? From my view, I should got 346 when the second time call.

10

Hey @infura1 - just to confirm, the txn with nonce 345 was mined, correct? When you send a txn, you’ll get a hash, but that doesn’t necessarily mean it’s been mined, which could be why you’re seeing that “duplicate” nonce number.