Failed password or cancelled dialog causes nonce to get out of sync

[pjworrall]

I am using eth-lightwallet 2.4.3 with the hooked-web3-provider 1.0.0 and web3 0.15.3 . I was finding that some transactions never got transaction receipts. I noticed that txpool.status reported these transactions going into a queued status and I found that happens when the nonce provided is incorrect.

I found that a transactionCount method is used and assume that is to determine the next appropriate tx nonce value. I found that if the password dialog prompt by eth-lightwallet did not receive a valid password the nonce appeared to be incremented anyway resulting in a subsequent tx nonce being too high. This resulted in that tx being placed in the "queued" state. Any subsequent transactions would have the nonce incremented again and also end up in the "queued" state.

So the ethereum node continues to add all tx produced via eth-lightwallet to the "queued" state because it needs a tx with the missing nonce to be submitted. Once it is then all the "queued" tx get processed.

If I restart the app with eth-lightwallet and produce a tx it appears to use the transactionCount to again determine the next nonce. If the password processing works then that tx has the correct nonce so it goes straight onto the "pending" status and gets processed. As it fills the gap all the other transactions then get processed.

Lots of words I know : - ) . Sorry. Summary:

transactionCount 1, password correct, tx nonce: 2 , mined
transactionCount 2, password incorrect, - not submitted
transactionCount 1, password correct, tx nonce: 3, queued because nonce incorrect
restart app.
transactionCount 1, password correct, tx nonce: 2, mined and previous transaction also mined
transactionCount 2, password correct, tx nonce: 3, mined

So somewhere the nonce is getting incremented when it shouldn't. I tried to walk the code to find it but keep getting lost...any pointers. I'll fix it if someone can point it out :-)

Of course if it is likely to be my poor use of it I willingly accept the blame but I am sure this is going on in the bit that builds the transaction options.

[pjworrall]

I discovered this problem is probably due to something in the hooked-web3-provider so I am looking for the solution there.

[pjworrall]

oh yes... ConsenSysMesh/hooked-web3-provider#9 .