@cgeek@1000i100 Pouvez-vous vérifier dans Cesium2 l’ordre des appels dans le batch pour migrer une identité ?
Si vous faites batchAll[changeOwnerKey, transferAll], cela échouera avec le runtime 1100 qui sera déployé sur la G1 v2 à cause de ce correctif :
Assurez-vous de faire votre batch dans cet ordre : batchAll[transferAll, changeOwnerKey]. Cela fonctionnera même s’il y a des frais, car ceux-ci sont prélevés en phase de pré-exécution. Ainsi, lors du deuxième sous-appel du batch, il est ok que l’ancien compte soit déjà vide.
@vjrj Could you verify in G1nkgo the order of the calls in your batch when migrating an identity?
Make sure to structure your batch in this order: batchAll[transferAll, changeOwnerKey]. This will work even if there are fees, since fees are deducted during the pre-execution phase. Therefore, during the second sub-call of the batch, it is expected that the old account may already be empty.
Ce n’est pas correct. Si la nouvelle clé n’a pas encore de monnaie, alors la migration du compte échouera. C’est un bug que 99 % des utilisateurs vont expérimenter à coup sûr ; cela me semble essentiel de le corriger.
Il est préférable de le faire en une seule transaction (extrinsic) : batchAll[claimUds, transferAll, changeOwnerKey].
A quoi bon faire un claimUd ici ? Par principe c’est bien de claimUd par principe dès qu’on peut, mais les DU non réclamé sont lié à l’identité, pas au compte, donc le changeOwnerKey n’aura aucun impact là dessus ont est d’accords ?
Oui c’est pour ça que dans Cesium dans l’écran de migration il est obligatoire de sélectionner un portefeuille non vide. Si le portefeuille est vide, la ligne est grisée et propose un bouton pour verser une Ğ1 puis le processus reprend automatiquement.
Je n’avais pas les batch en tête quand je l’ai fait donc je me suis compliqué la vie, mais ça fonctionne. Au final je suis précisément tombé sur le bug mentionné.
Pour l’utilisateur, il serait plus simple qu’il y ait une première commande qui envoie 1 ou 2 ǧ1, puis les autres commandes.
J’ai été surpris de voir qu’il fallait d’abord envoyer une ǧ1, pour faire une migration.
Il suffirait que Cesium2 fasse comme je l’ai recommandé : soumettre une seule transaction/extrinsic batchAll[transferAll, changeOwnerKey]. Avec ce changement, il ne serait pas nécessaire que le nouveau compte reçoive des ǧ1 au préalable.
@cgeek Ce serait bien que tu changes ça aussi pour rendre Cesium2 plus résilient aux échecs : actuellement, si l’app ou le smartphone crash ou se coupe entre les deux transactions, le compte peut se retrouver dans un état intermédiaire non géré. Avec une seule transaction, cela deviendrait atomique : le compte est entièrement migré ou pas du tout.
Corrigé aussi dans Tikka. Release demain si tout va bien !
Merci pour toute les reviews et les discussions, qui m’ont fait corriger Tikka car j’avais oublié des choses. Pour être le plus prêt possible le 8 mars.