C’est le format de cette address que tu donnes qui ma mis sur la voie.
Elle commence par 14 et non 5 comme le voudrait le prefix 42 de la ĞDev.
C’est un bug du SDK polkawallet que j’utilise. Il manque un await quelque par de leur côté (du moins c’est ce que je pense avoir identifié comme étant la source du bug) ce qui fait que lors de la génération de l’address à partir de la seed, l’address affiché est d’abords avec le préfix de Kusama, ce qui donne ce type d’address.
Dans mon code j’ai donc un sleep 0.02 qui attends donc 20 milliseconds que le prefix soit bien appliqué au KeyPair généré, avant de retourner le résultat.
Si ce delay n’est pas suffisamment long sur ton téléphone, le prefix du KeyPair n’est toujours pas chargé, le portefeuille est donc enregistré avec la mauvaise address.
Dans ton cas, le delay est à la limite, ce qui fait que le résultat est aléatoire (les bugs qu’on préfère).
J’ai augmenté ce delay à 50ms en attendant, mais il faut que je règle le problème en amont.
Je vois que tu ne l’as pas explicitement taggé, il a certainement oublié ta PR depuis le temps, il faut le tagger en lui demandant gentiment s’il pense pouvoir merger ces fix bientot
Que veux tu dire par là ?
L’écran t’affiche un timeout au bout de 12s, mais tu constates que le paiement a bien été effectué quand tu va voir le solde de ton portefeuille ?
Si c’est le cas non ce n’est pas normal à ce stade du développement.
Quel était le montant de ce virement, de quelle addresse vers quelle addresse stp ?
J’ai mis le timeout à 12s, ce qui correspond au passage de 2 blocs.
Si Duniter ne renvoi toujours aucune réponse au bout de 12s ce n’est pas normal.
N’est-ce pas @elois ? Est-ce qu’il est possible qu’un extrinsic se termine avec succès après 12s d’exécution ?
Il peut y avoir plusieurs raisons coté duniter-v2 pour lesquelles cela arrive:
La souscription RPC ne garantit pas de retourner la notification, il se peut que tout se passe très bien mais que le serveur RPC ne retourne aucune notification, c’est toutefois censé être très rare, ça arrive généralement quand le serveur RPC est surchargé de requêtes, il va alors skip des notifications pour prioriser le traitement d’autres requêtes.
La réponse vient quand l’extrinsic est introduit dans 1 bloc, ce qui nécessite que ce dernier arrive dans la pool d’un nœud qui va forger un bloc. Plus il y a d’authorités, plus ça peut être long. Je ne sais pas combien de blocs il faut attendre en moyenne selon le nombre d’authorités, on va le voir par l’expérience, ce serait chouette que quelqu’un fasse des stat là-dessus
L’extrinsic expire avant de pouvoir être inclus dans un bloc (ne peut arriver que si la blockchain est surchargée)
L’extrinsic deviens invalide avant de pouvoir être inclus dans un bloc (par exemple si un autre extrinsic du même issuer avec le même nonce passe entre-temps).
Si l’exécution de l’extrinsic panic ou par en boucle infinie.
Peut-être d’autres cas possibles auxquels je ne pense pas
À priori, seule la raison “panic ou boucle infinie” constitue un bug, pour savoir si on est dans ce cas il faut rééxécuter l’extrinsic localement contre le même state, ce qui est possible avec des outils de testing comme try-runtime, mais ça demande du développement coté node/host pour pouvoir l’utiliser (c’est dans ma roadmap).
EDIT: @poka note aussi que même si le serveur RPC t’envoie bien la notif, il est possible que ta lib RPC où ton wallet Ğecko ne relaye pas la notif dans certains cas pour “whatever reason”, ça peut être notamment des problèmes de gestion de l’asynchrone
Des travaux pourront être fait plus tard pour le rendre compatible PC ou web, mais pas avant un moment je pense.
Il te faut utiliser Tikka sur PC
(edit: A noter qu’il doit en théorie être possible de lancer Ğecko sur Windows 11, étant donnée qu’ils prétendent que les app Android sont désormais executablent nativement, mais j’ai pas testé… A quand pour Ubuntu?)
J’essaie de faire un virement vers D9D2zaJoWYWveii1JRYLVK3J4Z7ZH3QczoKrnQeiM6mx
J’ai cherché Éloïs, j’ai sélectionné le compte, j’ai tapé sur « faire un virement » (les deux flèches).
J’ai mis un montant de 10 gdev, je tape sur « envoyer le virement » je saisis le mot de passe, j’arrive sur l’écran « envoi en cours » j’ai la flèche qui tourne, et au de quelques secondes (12 environ) j’ai l’erreur Time Out. Et mon solde n’a pas bougé, toujours 47 gdev.
Et devoir taper sans arrêt mon mot de passe, c’est assez casse pieds, est-ce que ça va rester comme ça ?
Perso je trouve ça bien que chaque client se spécialise pour certains types de plate-forme uniquement, ça permet de monter en qualité et donc de fournir une meilleur expérience utilisateur.
Je pense que les développements sur Ğecko devraient se concentrer exclusivemet sur l’UX mobile, et les développement sur Tikka exclusivement sur l’UX desktop.
@poka pour les personnes ayant un mobile qui est sur un os libre, ce serait bien d’avoir une version linux mais dont l’UX et l’interface reste conçue pour les écrans mobiles, tu voit ce que je veut dire ?
Moi je vois parfaitement et ça répondrait à mon besoin vu que mon tél actuel est sous Linux. Il y a aussi des widgets qui adaptent leur comportement selon la taille de l’écran. Donc possible en théorie de servir les deux mondes.
C’est ma faute: Ce que je vous ai pas dit c’est qu’actuellement Gecko en encore connecté au noeud GVA d’elois, mais en scrède… Du coup si tu recherche n’importe quoi d’autre qu’une address gdev, comme le pseudo “elois”, la recherche va tapper dans GVA et Cs+, donc de la G1.
Et je n’avais tout simplement pas remarqué que tout le workflow de paiement semble fonctionner comme si tout allait bien, oklm, et tenter de payer des ĞDev vers des comptes Ğ1, jusqu’au timeout car c’est une address invalide pour Duniter je présume.
C’est drôle, mais je vais retirer totalement GVA et Cs+ pour les prochains builds, et limiter la recherche…
… je m’y était attaché, j’ai passé du temps dessus ^^
Si je comprend bien, si une adresse (clé publique) ne commence pas par 5, elle ne correspond pas à la gdev.
D’où l’intérêt de toujours indiquer les clés publiques concernées quand on signale un comportement inattendu.
Impossible actuellement, la dépendance flutter_inappwebview du package de polkawallet_sdk n’est compatible que sur Android et iOS actuellement comme tu peux le voir sur pub.dev.
Mais il y a des isses à ce sujet qui évoluent depuis un moment, donc j’ai bon espoir que cette dépendence soit comptabile desktop un jour.
Sinon il faudra totalement tout revoir et utiliser un binding Rust à la place de la webview, ce qui serait bien plus performant, mais là ya du taf …
taf dans lesquels je ne pourrais pas ne lancer tellement je fais déjà beaucoup trop de choses, je pense que @tuxmain et @HugoTrentesaux auraient les compétences pour le faire, mais ils sont également plus utiles sur des taches plus prioritaires.
Il vaut mieux attendre que flutter_inappwebview devienne compatible linux, ou contribuer à ce package pour apporter cette compatibilité
En parlant de binding Rust, depuis quelque temps il y a un packer flutter qui fait sensation:
Il est optimisé pour binder du Rust en flutter, il n’y a plus besoin de passer par l’API type C pour ça.
Et il est compatbile Desktop et mobile
Mais de toute façon, pour le moment j’apprécie de rester collé à l’API de la lib polkawallet-js, cela semble bien fonctionner ainsi.
Vouloir passer sur un binding Rust rajoute du taf nécessaire uniquement si on veut optimiser les perf de Gecko.
Dans l’idéal il faudrait benchmarker Gecko, je n’ai juste pas encore pris le temps de m’y plonger…
Mais c’est évident que se passer de la headless webview augmenterait les perfs, je ne sais juste pas à quel point …
Il faudra mesurer ça un jour pour savoir si ça impacte réellement l’expérience utilisateur, si c’est pour gagner 15ms ça ne sert à rien, mais quelques centaines de ms là ça commence à se sentir à l’utilisation
Au delà des temps d’exécutions, il y a aussi l’impact en RAM qu’il faut voir, et les temps de CPU utilisé en fond de l’app, qui consomment de la batterie.
C’est tout ça qu’il faudrait regarder, Flutter a les outils pour, je regarderai à l’occasion.
En parlant d’optimisation, il y a une chose que je dois changer assez rapidement, c’est la souscription que je fais aux blocs.
Actuellement chaque bloc reçus toutes les 6s d’éclanche un notifyListener à tous les widget qui écoute ce Provider.
Ces parties de widget sont par exemples tous les champs solde et identité qu’on rencontre dans l’app.
Donc quand vous êtes sur un écran avec 3 wallets sous vos yeux dans l’accueil de vos portefeuilles, concrètement toutes les 6s, 3 requêtes de soldes sont faites pour les réactualiser.
J’ai conscience du manque d’optimisation que c’est, il faudrait plutôt que je souscrive à chaque balance ou élément du storage individuellement, et arrêter cette souscription générale à chaque nouveaux blocs qui rafraîchi tous les widgets contenants des éléments du Storage dans l’arbre de widget actuellement ouvert…
Voilà le genre de truc que j’aimerai benchmarker aussi.
Mais avant de parler d’optimisation il faut surtout que je refasse tous les tests d’intégrations, de zero…
J’attends un peu le dernier moment pour m’y remettre un bon coup, mais c’est vrai que ça demande beaucoup de temps, et c’est fastidieux, surtout là je dois traiter tous les workflow existants, il commence à y en avoir pas mal.
Je veux bien m’occuper des tests, mais j’aimerai bien que parallèlement certains m’aident à configurer la CI de Gecko, parce-que ça aussi je me rends compte à quel point ce sera indispensable pour faciliter les publications et les tests.
Peut être que @1000i100 ou quelqu’un roadé en CI pourrait regarder ça avec moi à l’occasion ?
J’ai cherché une clé gdev 5GFEEx7kqvP4QEPCAXkALeYCG7m8DiA5LQ4YzW62j7FytQyg
Et je l’ai trouvé
J’ai fais un virement de 10 gdev, et ça a bien fonctionné.
Bon après le retour sur l’écran de saisie de virement, je trouve ça moyen. Surtout que je vois pas bien comment sortir de cet écran.
Mais j’ai réussi à faire un virement, je suis content.
