Pour vous le signaler, hier au ĞMarché de Noël, ça a été un peu le bazar au niveau des transactions, je sais pas si Duniter à fumé, on a atteint un pic de transactions important je pense.
On a relevé des incohérences au niveau des transactions a l’affichage, du style :
Des transactions qui se doublent ou se triplent.
Des transactions non exécutées
Des transactions en échec
Des transactions invisibles une fois validées
Des transactions en attente de réception
C’est un retour des personnes qui étaient autour de moi. La connexion était pas top, j’imagine que Cesium a dû saturer.
Aujourd’hui encore j’ai des transactions qui passent pas.
Vous avez remarqué des trucs en particulier de votre côté ?
Merci Benoît, on continue à regarder les comptes, toujours des virements en attente ou en échec. On a du mal à comprendre et à savoir ce qu’il faut faire. S’il faut changer de noeud, je crois que je ferai un tuto que je mettrai sur le site Axiom
Les transactions peuvent aussi être restée en piscine d’une noeud.
Dans ce genre de cas, il serait utile que vous nous indiquiez le noeud sur lequel vous avez fait vos transactions.
le message: "transactions en attente/echec " avec la liste des 7 transactions a disparu de son ecran compte membre cesium !!
(il nous reste que la photo plus haut comme preuve de « promesse de paiement »)
en cherchant dans les blocs j’ai trouvé par exemple la transaction du compte CWvcg74V vers Nadou ici sur le noeud de Liegeois, Marc :
J’avoue ne pas comprendre pourquoi ni comment les transactions n’ont pas été envoyées par défaut à tous les noeuds membres visibles au moment de leur réalisation…
Avec cette méthode la probabilité de réussite et la rapidité de réalisation du vidage des piscines serait accélérées.
On peut réfléchir aussi à ce qu’un client stocke le document relatif à la transaction et le renvoie lors de son lancement de son propre chef jusqu’à vérifier son succès en inscription dans la blockchain, ainsi cela permettrait aux utilisateurs de ne pas se retrouver sans possibilité d’action pour résoudre le problème, renvoyer le document manuellement à la limite vers un ou plusieurs noeuds choisis leur permettrait de débloquer la situation. Actuellement c’est comme si le noeud cible avait confisqué la transaction sans que l’utilisateur puisse retrouver la main sur le document.
Il s’agit d’isoler la couche réseau de la couche client. je ne comprends même pas l’utilité de choisir le nœud sur lequel on envois une transaction ou de n’envoyer qu’une à la fois.
Itérativement c’est du délais dans le meilleur des cas et de la souffrance mental sinon, ton client bittorent ne te demande pas de choisir le prochain serveur.
est-tu seulement capable de faire une tel mesure ? cette valeur sera-t’elle la même la seconde d’après ?
une poignée de serveurs suffisent… il ne faudrait pas déléguer le travail du réseau au client non plus
Le noeud serveur est censé broadcast le document sur les réseau a son tour. Mais il semblerait que ce ne soit pas parfaitement fonctionnel en cas de grosse montée en charge…
