stacks-network
ConflictingNonceInMempool error thrown incorrectly
Describe the bug
Broadcasting a transaction using the StacksJs broadcastTransaction function yields a conflictingNonceInMempool error even though transaction is broadcast.
Context
In my application I am creating and broadcasting multiple transactions sequentially in a cron job. Transactions are created with locally specified nonce values. At the start of every cron job local wallet nonce information is updated via this endpoint: https://api.testnet.hiro.so/extended/v1/address/{principal}/nonces and all subsequent broadcasts use localNonce++.
Any gaps in nonces are filled by high fee, dummy transactions. The cron job run every 5 mins.
To Reproduce The problem has been difficult to reproduce. It shows up when I attempt to broadcast 50+ transactions (I maintain multiple wallets) in a single cycle.
What happens
Occasionally, during the broadcast of a transaction the API/function returns a conflictingNonceInMempool error, but upon checking the transaction on the API after a few minutes its found that the transaction with the same txid was broadcast with the correct nonce (the locally calculated value) and it even confirms.
Originally I thought this was a local issue (as in, in my code) but after lots of tinkering and logging I am sure this is originating from elsewhere.
Expected behavior The API should not return an error if the broadcast was successful.
Screenshots
Attaching some logs from my application for the transaction: 0x3b57e388e2c5a1994143766497d9c0ae256e10a3579236a344b99e464320d1b2
Some other examples
- 0x9651928f4da2aecae514f40207adb62eccf71aa04ae5c9ce0da7a9e4ab32ed11
- 0x762ffbbfce4adddc5ce4c1263e978068d660e19bb0eebfdf93e15954fcd36b50
Frequency Out of 450 broadcasts, there were 9 instances of this behavior.
If you're getting conflictingNonceInMempool, it makes sense that the TX would eventually confirm, because the node is saying that you've essentially already broadcasted the transaction. Without seeing your script, it's hard for me to judge whether this might just be due to some parallelization or timing issue in how you're broadcasting transactions.
