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
Back-end now sends a txDropped when a transaction is no longer in the mempool and not replaced (speedup/cancel) or added to a block.
Note that this feature is not necessarily a global state as it depends in specific node mempools. It is possible to a tx to receive txConfirmed/txFailed after a txDropped.
Support includes default and custom notification messages, as well as custom notifications event handler.
The text was updated successfully, but these errors were encountered:
@cmeisl I have a branch setup with code that implements this feature in this commit: 848da94
Off the top of my head I can't think of a way to test this functionality. Is there a way that we can get a transaction in to the txPool and then get it to be intentionally dropped?
Also to be clear, you are saying in the above issue that a transaction can get dropped from the txPool and then get back in to the txPool without any additional actions by the dapp/user/Assist? The above commit implements that assumption and doesn't remove the transaction from the internal transactionQueue so that Assist can handle any new status updates that come through for that transaction.
I am also not sure whether this should be an "error" styled notification or a "pending" styled notification. The above commit implements it as an "error" styled notification.
Back-end now sends a
txDropped
when a transaction is no longer in the mempool and not replaced (speedup/cancel) or added to a block.Note that this feature is not necessarily a global state as it depends in specific node mempools. It is possible to a tx to receive
txConfirmed
/txFailed
after atxDropped
.Support includes default and custom notification messages, as well as custom notifications event handler.
The text was updated successfully, but these errors were encountered: