« Le mot “Removed” placé dans le suivi des transactions peut facilement être lu comme “échec”, mais quand je vois l’événement RUES de @Dusk , je fais d’abord une pause, car le fait qu’une transaction quitte le mempool local ne signifie pas qu’elle a été rejetée par la blockchain. Ce n’est pas un jeu de mots : dans la documentation officielle de Dusk, transactions/removed signifie uniquement qu’elle sort d’un mempool local d’un nœud. Les raisons peuvent être : inclusion dans un bloc, remplacement par une transaction conflictuelle avec un gasPrice plus élevé, expiration, éviction par capacité, ou simplement le fait que la transaction conflictuelle quitte aussi le mempool. À partir d’un seul événement, le système ne vous dit pas le résultat final.
Cela m’a amené à reconsidérer l’expérience développeur de $DUSK : lorsque le moniteur mappe removed sur un échec, l’alerte en arrière-plan peut arriver trop tôt ; mais s’il le considère comme un succès, il peut aussi passer à côté des transactions réellement évincées. Un champ de statut sépare en fait “ce qui se passe devant les yeux du nœud” de “ce que le registre conserve en dernier”. En pratique, les scénarios de charge sont assez ordinaires : après un transfert, l’utilisateur reçoit removed et le wallet lui indique “veuillez réessayer”. Il renvoie alors une transaction, puis constate que la première est déjà incluse dans un bloc. Résultat : il paie un gas supplémentaire, et le support doit ensuite expliquer quelle transaction était valide. Un message d’erreur basé uniquement sur l’événement, sans consulter le registre, amplifie la vue locale jusqu’à en faire un fait.
Donc je ne considérerai pas removed dans RUES comme un signal d’échec. La documentation de @Dusk donne une approche plus sûre : vérifier la transaction et l’état du bloc avant de décider de réessayer. Ensuite, je vais vérifier si le wallet affiche séparément pour l’utilisateur “sortie du mempool local” et “résultat final : c’est précisément le genre de détail que Dusk met en place pour aider les utilisateurs à moins tomber dans le piège. #dusk
Cela m’a amené à reconsidérer l’expérience développeur de $DUSK : lorsque le moniteur mappe removed sur un échec, l’alerte en arrière-plan peut arriver trop tôt ; mais s’il le considère comme un succès, il peut aussi passer à côté des transactions réellement évincées. Un champ de statut sépare en fait “ce qui se passe devant les yeux du nœud” de “ce que le registre conserve en dernier”. En pratique, les scénarios de charge sont assez ordinaires : après un transfert, l’utilisateur reçoit removed et le wallet lui indique “veuillez réessayer”. Il renvoie alors une transaction, puis constate que la première est déjà incluse dans un bloc. Résultat : il paie un gas supplémentaire, et le support doit ensuite expliquer quelle transaction était valide. Un message d’erreur basé uniquement sur l’événement, sans consulter le registre, amplifie la vue locale jusqu’à en faire un fait.
Donc je ne considérerai pas removed dans RUES comme un signal d’échec. La documentation de @Dusk donne une approche plus sûre : vérifier la transaction et l’état du bloc avant de décider de réessayer. Ensuite, je vais vérifier si le wallet affiche séparément pour l’utilisateur “sortie du mempool local” et “résultat final : c’est précisément le genre de détail que Dusk met en place pour aider les utilisateurs à moins tomber dans le piège. #dusk
