Registrar has nonce issues if issuing two tx's without confirmation

[hstove]

The registrar uses a naive approach for getting the current nonce - which is just to call /v2/accounts and get the current nonce. This does not reflect any tx's in the mempool. If the registrar makes a name_update tx and then makes another one before the first was confirmed, the second tx will get rejected due to a conflicting nonce error.

This can be worked around with a longer "batch interval" configuration - but it's not ideal.

Two options to do a better job:

• Get all pending tx's for the registrar payer, and if there is a pending tx, use the highest nonce + 1
• Store tx nonce's in the database, and use the next highest one

[314159265359879]

Isn't this a more general problem with nonce's?
When I make a transaction in the Boom wallet (nonce 10), for example to transfer an NFT, then return to the hiro web wallet to make a transfer it will try to do so with the same nonce (10), if the Boom transaction was not yet confirmed.
Could the application simply count the number of pending transactions (x) and add those to nonce value (10+x) of the last confirmed transaction? Counting on there being only one transaction pending may not suffice anyway.

If all applications are experiencing these sort of issues should this be solved elsewhere, could it merit a SIP?

[markmhendrickson]

Does the registrar retry transactions upon failure for whatever reason, nonce or otherwise?

[asimm241]

Does the registrar retry transactions upon failure for whatever reason, nonce or otherwise?

Yes, It periodically checks for subdomains with received status in the local DB and calls name-update, for them.

[markmhendrickson]

Great 💪 Given those retries, this doesn't appear urgent for resolution before we deploy the updated registrar for mainnet.