“Removed” is easy to misread as “failed” in transaction monitoring, but when I saw the RUES event for @Dusk , I paused first—because a transaction leaving the local mempool does not mean the chain has rejected it. This isn’t wordplay. In Dusk’s official documentation, transactions/removed only indicates that it has left a node’s local mempool. The reason could be that it was included in a block, replaced by a conflicting transaction with a higher gasPrice, expired, evicted due to capacity, or simply that a conflict transaction left the mempool. Looking at this single event alone, the system doesn’t tell you the final outcome.
This made me rethink the developer experience around $DUSK . When the monitor maps removed to “failure,” the backend alerts too early; but if it maps it as “success,” you might miss transactions that were truly evicted. A single status field effectively splits what happened “in front of the node” from what the ledger ultimately remembers. In real-world pressure scenarios—which are actually quite common—after a user sends a transfer, the wallet receives “removed” and prompts “please retry.” The user sends another transaction and only then discovers the first one was already included in a block, resulting in paying an extra gas fee and requiring customer support to explain which transaction was the valid one. If you generate error messages based on events without checking the ledger, you end up magnifying the local view into a fact.
So I won’t treat RUES’s removed as a failure signal. The documentation for @Dusk points to a safer approach: look up the transaction and the block status to decide whether to retry. Next, I’ll check whether the wallet shows “locally removed” separately from the “final result” to users—that’s the kind of detail Dusk uses to help users avoid pitfalls. #dusk
This made me rethink the developer experience around $DUSK . When the monitor maps removed to “failure,” the backend alerts too early; but if it maps it as “success,” you might miss transactions that were truly evicted. A single status field effectively splits what happened “in front of the node” from what the ledger ultimately remembers. In real-world pressure scenarios—which are actually quite common—after a user sends a transfer, the wallet receives “removed” and prompts “please retry.” The user sends another transaction and only then discovers the first one was already included in a block, resulting in paying an extra gas fee and requiring customer support to explain which transaction was the valid one. If you generate error messages based on events without checking the ledger, you end up magnifying the local view into a fact.
So I won’t treat RUES’s removed as a failure signal. The documentation for @Dusk points to a safer approach: look up the transaction and the block status to decide whether to retry. Next, I’ll check whether the wallet shows “locally removed” separately from the “final result” to users—that’s the kind of detail Dusk uses to help users avoid pitfalls. #dusk
