Observed on devnet v0.13 on the network monitor's account.
The ntx has failing network transactions rejected by the block-producer due to
input notes with given nullifiers were already consumed by another transaction
which indicates that the nullifiers already exist. Since this account is only being interacted with by the ntx itself, we can conclude that the ntx is creating conflicting transactions.
This implies that the ntx is creating consecutive transactions consuming the same notes. What should happen is that the actor updates its local state to match the transaction going through - including removing the input notes as candidates.
A simple but effective way to implement this is once the actor successfully submits a transaction, it enters a new state where it simply waits for the mempool event for this transaction. And then updates its own state accordingly, and continues looking for the next transaction to submit. An escape hatch (in case a bug causes this transaction event to never arrive) is to add a length timeout to this state e.g. if no matching event arrives after 5 minutes, abort, or move to a resync stage. Probably just aborting the actor is fine for now.
tbh I thought we had code for this but maybe I'm just remembering the previous implementation.
Observed on devnet v0.13 on the network monitor's account.
The ntx has failing network transactions rejected by the block-producer due to
which indicates that the nullifiers already exist. Since this account is only being interacted with by the ntx itself, we can conclude that the ntx is creating conflicting transactions.
This implies that the ntx is creating consecutive transactions consuming the same notes. What should happen is that the actor updates its local state to match the transaction going through - including removing the input notes as candidates.
A simple but effective way to implement this is once the actor successfully submits a transaction, it enters a new state where it simply waits for the mempool event for this transaction. And then updates its own state accordingly, and continues looking for the next transaction to submit. An escape hatch (in case a bug causes this transaction event to never arrive) is to add a length timeout to this state e.g. if no matching event arrives after 5 minutes, abort, or move to a resync stage. Probably just aborting the actor is fine for now.
tbh I thought we had code for this but maybe I'm just remembering the previous implementation.