“La palabra ‘Eliminado’ se puede leer fácilmente como ‘fallido’ en la supervisión de transacciones, pero cuando vi el evento RUES de @Dusk me detuve un momento, porque que una transacción salga del mempool local no significa que haya sido rechazada por la cadena. Esto no es un juego de palabras. La explicación oficial de Dusk sobre transactions/removed solo indica que salió del mempool local de algún nodo; el motivo puede ser que se incluyera en un bloque, que una transacción en conflicto con un gasPrice más alto la sustituyera, que haya expirado, que haya sido expulsada por capacidad, o simplemente que la transacción en conflicto saliera. Mirando solo este evento, el sistema no te dice el resultado final.

Esto me hace reconsiderar la experiencia de desarrollador del $DUSK : cuando el monitor mapea removed como fallo, el backend avisa demasiado pronto; pero cuando lo trata como éxito, podría pasar por alto las transacciones que realmente fueron descartadas. Un campo de estado en realidad separa en dos capas lo que “ocurre frente a los ojos del nodo” y lo que “el libro mayor recuerda al final”. El escenario bajo presión es bastante común: después de que el usuario transfiera, la billetera recibe removed y muestra “por favor, inténtalo de nuevo”. Luego, al enviar otra transacción, descubre que la primera ya se incluyó en un bloque, con lo que termina pagando un gas extra; además, el soporte tiene que explicar qué transacción fue la válida. Si el aviso de error no se basa en el libro mayor y solo mira los eventos, entonces la vista local se amplifica hasta convertirse en un hecho.

Por eso no consideraré el removed de RUES como una señal de fallo. La documentación de @Dusk ofrece un camino más seguro: revisar la transacción y el estado del bloque antes de decidir si reenviar. A continuación, veré si la billetera muestra por separado “salió del entorno local” y “el resultado final” al usuario; ese es el tipo de detalle con el que Dusk ayuda a que los usuarios eviten caer en trampas.#dusk