Sending Ethereum transactions requires incrementing the nonce properly. In a typical application, there can be concurrent and/or consecutive requests to transfer from the same address.
Most solutions I've seen use getTransactionCount(fromAddress, 'pending') to set the nonce of the transaction, which is then sent using sendRawTransaction.
If two requests happen in the same block, then getTransactionCount(fromAddress, 'pending') should increase between the requests. However, this doesn't seem to be the case:
> web3.eth.getTransactionCount("0xf82e...", "pending");
5
> web3.eth.sendTransaction({from: "0xf82...", to: "0xf1c...", value: 42000000000000000});
I0624 15:57:41.848826 eth/api.go:1193] Tx(0xbd094a59eb8f05653f35fa93a9254db95bc6b9b5bdd3b95aedda27bb781545f9) to: 0xf1c...
"0xbd094a59eb8f05653f35fa93a9254db95bc6b9b5bdd3b95aedda27bb781545f9"
> web3.eth.getTransactionCount("0xf82...", "pending");
5
> I0624 15:57:59.315075 miner/worker.go:337] 🔨 Mined block (#4529 / 7788e873). Wait 5 blocks for confirmation
I0624 15:57:59.315639 miner/worker.go:555] commit new work on block 4530 with 1 txs & 0 uncles. Took 529.458µs
I0624 15:57:59.315664 miner/worker.go:433] 🔨 🔗 Mined 5 blocks back: block #4524
I0624 15:57:59.315989 miner/worker.go:555] commit new work on block 4530 with 1 txs & 0 uncles. Took 310.783µs
> web3.eth.getTransactionCount("0xf82...", "pending");
6
As you can see, getTransactionCount(from, 'pending') only increases after the block has been mined. In result, the second request uses the same nonce and the second transaction fails (queued, dropped, etc.).
Is this a bug with getTransactionCount? I'd assume it should return an increased nonce, because 'pending' has been specified.
Also, do we need to manage the nonce on the application side or is the some other solution to this? A stateless solution on the application side would be much simpler to manage.
getTransactionCountwithpendingonly increases when a block was mined for me. Smells like a bug and will investigate further. – murrekatt Aug 5 '16 at 7:29