Le 2 mars 2019 j’ai posé un stand de nourriture, des parts de diverses quiches, au Festi’June à Toulouse. 40 parts, tout est parti en 3 heures. Je n’ai pas tenu le stand, il y avait un panneau avec la clé publique, le pseudo “miam” le pseudo Césium+ “Miam Miam”, l’avatar, le QR code, le prix.
J’ai pris 4 parts pour ma famille. 26 parts ont été payées. 10 parts n’ont pas été payées. Bonjour le ratio.
Commençant à m’inquiéter sur l’état d’esprit de la journée, je me suis dit qu’il valait mieux attendre quelques jours, certains paient en rentrant chez eux. Ce qui ne s’est visiblement pas passé comme ça.
Donc le lundi 4 mars, je m’aperçois que 2 transactions sont en échec, sans pouvoir visualiser qui et combien.
Je ne sais donc pas combien exactement de parts de tartes sont concernés par des refus de payer de la part des clients et combien font l’objet de l’ignorance par le client que la transaction n’est pas passée.
Serait-il possible et/ou envisageable qu’une notification de transaction échouée soit visible dans césium ?
J’en profite aussi pour faire un appel à tout le monde d’honorer ces parts de quiches en jouant le jeu de la confiance.
Effectivement les développeurs méritent d’être payés en échange de leur travail, le compte “Développeurs de Duniter” est déjà là pour ça . Certes c’est jardin qui fait la réclamation à partir d’un problème personnel mais cette suggestion peut être bénéfique pour tout le monde.
Mais, tu es sûr qu’il n’y a pas déjà une notification quand une transaction envoyée échoue ? C’est peut-être juste que les gens ne regardent pas souvent Cesium ni leurs mails.
Il est également possible que les transactions aient parfaitement fonctionné mais qu’elles soient tombées dans un fork, si le nœud auquel était connecté le cesium client était désynchro au moment de la transaction. Dans ce cas, la transaction n’apparaîtrait même pas en erreur, à moins de faire une analyse à posteriori des différents fork, et là c’est chaud à faire techniquement. L’idéal étant que le destinataire vérifie rapidement si les transactions sont bien arrivées sur son compte, en vérifiant que son nœud est bien sur la chaîne principale. C’est sûr, il y a encore du travail à faire de ce côté-là. Une idée serait de pouvoir remettre les transactions dans les piscines lorsqu’il y a eu un fork… mais que se passe-t-il si l’utilisateur les a republiées sur la branche principale depuis ?
@jardin je pense que tu mélanges 2 choses vraiment différentes dans le même post et même si je comprends très bien pourquoi, ce n’est pas forcément facile à gérer derrière, tant au niveau de la cohérence des posts sur le forum que des réponses apportées. Il y a d’une part ta gestion un peu négligente du stand et du coup la confiance dans les visiteurs du marché, et d’autre part un problème technique de vérification des transactions. Pour le premier, clairement, on ne peut rien faire sinon te dire de faire mieux la prochaine fois. pour le deuxième c’est un problème complexe qui fait intervenir de nombreux paramètres. Cette combinaison explique (mais n’excuse pas à mon avis) l’attaque frontale que tu te prends en pleine figure…
@Junidev je pense que le problème technique de validation des transactions soulevé est réel et assez général et il est très sain d’en parler. @jardin n’a pas demandé à qui que ce soit de faire quoi que ce soit, il n’a fait qu’une suggestion (« serait-il possible et/ou envisageable », c’est loin d’être Stalinien…) face au problème qu’il a rencontré. Du coup, tu pars un peu dans les tours pour rien ce qui nuit de mon point de vue à la sérénité des discussions.
Dans des anciennes versions de Cesium, je gardais en mémoire les transactions (TX) émises, afin de pouvoir vérifier si elles étaient passées. Je crois bien que j’ai du supprimé ce code, car la gestion des piscines (dans les noeuds Duniter) permettait d’accéder à ces transactions non validées.
Je penses que Duniter doit maintenant faire le mnage plus régulièrement dans les piscines (notamment en cas de fork/rollback). Du coup, le besoin se fait à nouveau sentir.
@jardin as tu le temps pour ouvrir un ticket ? Tu l’as peut-etre déjà fait…
Quand au reste du post… @Junidev ah la la… Il me semble que les intentions du post de @jardin n’étaient pas agressives, ni même erronées. Je comprend même très bien le problèmes de transactions qui ne sont pas passées, sans notifications visibles !
Je suis d’accord en revanche que le titre n’a aucun rapport (“Problème de confiance”). C’est peut-etre d’avantage sur cela que tu as réagis ?
Est-ce possible d’envisager (un jour) de répondre à des posts sans impliquer/engager (trop) la personne et ses intentions (avec le “tu”, “on”, etc.) au profit du “je” ou “je penses que”. Je trouve cela moins agressif. Cela étant, il est bien entendu que je ne prétends pas maîtriser cet art pour autant !
Merci !
en jouant le jeu de la confiance.
. Certes c’est jardin qui fait la réclamation à partir d’un problème personnel mais cette suggestion peut être bénéfique pour tout le monde.
pour le deuxième c’est un problème complexe qui fait intervenir de nombreux paramètres. Cette combinaison explique (mais n’excuse pas à mon avis) l’attaque frontale que tu te prends en pleine figure…
Il me semble que les intentions du post de