You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From slack: the tx submission client:
it should check the mempool whether or not to request a tx at all
and then, I guess, again when it actually gets it
since it might have been inserted in the meantime
that last check is going to be very annoying actually now that I think about it
will be hard to avoid a race condition
From slack: the tx submission client:
it should check the mempool whether or not to request a tx at all
and then, I guess, again when it actually gets it
since it might have been inserted in the meantime
that last check is going to be very annoying actually now that I think about it
will be hard to avoid a race condition
To expand on the second check: the second check avoids adding a transaction already in the Mempool, which will cause the transaction to be rejected. This will pop up in the trace and might confuse users.
IMO, this is not a big deal, we can just do the first check so we don't request a transaction already in the Mempool. If we then request and receive the same transaction from two nodes, one of them will be rejected, so be it. #1743 will help with that, except that the wallet could still add the same transaction between the time we request it from another node and add it to the Mempool.
This would first require to fix the tx request client though.
Related but orthogonal: #1743
The text was updated successfully, but these errors were encountered: