Depuis quelques jours, césium ne fonctionne plus bien.
Sur Android (V1.7.13 ou V1.7.14), pas moyen de se connecter facilement, Message "Réseau injoignable) une fois connecté, en annulant le choix du noeud proposé en forçant le mode expert et le choix d’un noeud) les opérations n’apparaissent plus …
Sur Desktop (V1.7.13) Linux, idem, on ne voit plus ni les DU ni les opérations dans “mes opérations”, par contre, en passant par l’annuaire, on parvient à les voir …
Bref, ça merdouille …
Je crée ce sujet parce que de nombreux utilisateurs de smartphones sous Android se plaignent …
4 Likes
Pour appuyer la demande @Damery , j’ai les même retours.
Pour moi sur Android, impossible de se connecter (v1.7.13), et sur ordi (ubuntu) ça fonctionne (ext. Firefox, ext. Brave et Desktop) presque bien sauf le nœud Césuim+ de @kimamila (e-is.pro) qui est en rade
1 Like
J’ai temporairement résolu le problème du Cesium en important mon compte à l’aide du portefeuille G1nkgo.
5 Likes
ça contourne le problème, mais ça ne le résout pas…
1 Like
En attendant que Cesium corrige le bug ‘Searching for network’, nous avons testé qu’avec la version précédente de 1.6.12 il se connecte sans problème.
https://github.com/duniter/cesium/releases/download/v1.6.12/cesium-v1.6.12-android.apk
Pour les autres appareils : Release 1.6.12 · duniter/cesium · GitHub
4 Likes
Merci kapis , ça marche très bien en installant la 1.6.12
J’ai quand même émis une certification il y 48h , je l’ai vue sur mon compte durant 24h au moins .
Elle n’a jamais été visible ailleurs : wot-wizard.duniter.org , etc
J’hésite à l’émettre à nouveau …
Tu peux réémettre une certification plusieurs fois tant qu’elle n’est pas validée.
2 Likes
Merci Maaltir , effectivement .
Mais là , j’étais sur le nœud cgeek il me semble , j’étais libre de certifier depuis 48h et ma certification est restée bloquée une demi-journée .
Puis elle a été marquée comme validée uniquement sur mon compte Cesium .Impossible de la retrouver ailleurs …
Aujourd’hui, elle a complètement disparue .
Je ne veux pas surcharger mais j’aimerais tout de même continuer à fonctionner …
Nous traversons une période très particulière pour le fonctionnement de Cesium .Ça va paraître long pour beaucoup d’utilisateurs jusqu’en mars .
Grâce à cette version 1.6.12 , je viens de faire un virement sans problèmes , je vais donc retenter ma certification .
Donc je confirme que tout fonctionne bien avec cette ancienne version : paiement et certification effectués .
savez-vous à quoi c’est dû ? Des noeuds pourtant fonctionnels (visibles depuis la “liste des noeuds” et depuis cesium 1.6.12) ne sont plus joignables avec cesium. Est-ce un changement de version de duniter sur certains serveurs qui provoque cela ? Parce que la version de cesium 1.7.13 fonctionnait auparavant, donc c’est un élément extérieur qui doit provoquer cela…
https://demo.cesium.app/ est également hs puisque c’est la même version 1.7.13
Quand je regarde dans la console, j’ai énormément d’erreurs CORS, non seulement pour les noeuds Duniter mais aussi pour l’affichage des ‘nouvelles’ :
Blocage d’une requête multiorigine (Cross-Origin Request) : la politique « Same Origin » ne permet pas de consulter la ressource distante située sur Nouvelle version 1.7.9 de Cesium - #2. Raison : échec de la requête CORS. Code d’état : (null)
Je vois aussi cette erreur :
Content-Security-Policy : Les paramètres de la page ont empêché l’exécution d’une « eval » JavaScript (script-src) car elle enfreint la directive suivante : « script-src ‘self’ ‘wasm-unsafe-eval’ » (la valeur ‘unsafe-eval’ est manquante)
1 Like
Qu’en est-il des conséquences du changement d’heure sur la possible désynchronisation des noeuds ?
Hypothèse avancée par Yann Beauvois
Les ordinateurs sur lesquels sont installés les nœuds Duniter v1, ont dû automatiquement se mettre à l’heure d’hiver. Ça ne devrait pas être un problème, il y a des nœuds qui sont dans d’autres fuseaux horaires. Ça pourrait coïncider, car il est vrai que ce problème a été rapporté juste après le changement horaire.
Je pense que le problème se trouve au niveau de l’algorithme de Cesium v1.7.x qui sélectionne automatiquement un nœud :
La v1.6.x fonctionne selon :
Donc en attendant, l’usage de la v1.6 fait l’affaire le temps que quelqu’un résolve le problème en v1.7.
Je ne reproduis aucun de vos problèmes sur la v1.7.14 en mode dev web.
Si j’arrivais à reproduire, je pourrais tenter une correction pendant que je suis dans ce code, mais là je ne peux rien faire sans reproduire.
1 Like
Hier, il me semble que je n’avais pas le problème hier, aujourd’hui j’ai :
puis :
Dans la console, je vois cette erreur :
[platform] Not enough BMA peers on the main consensus block: 8 found. Will peek another peer...
Peut-être pas assez d’API BMA v1.8 fonctionnelles (problème CORS ?) et synchronisés !
Édition : je vois que les nœuds v1.9 sont exclus de l’algorithme :
[network] [#5] BMA endpoint [g1.asycn.io] is EXCLUDED (incompatible version 1.9.0) [network-services.js:1097](https://moul.re/cesium/maps/dist_js/dist/dist_js/app/services/network-services.js)
[network] [#5] BMA endpoint [duniter.pini.fr] is EXCLUDED (incompatible version 1.9.0) [network-services.js:1097](https://moul.re/cesium/maps/dist_js/dist/dist_js/app/services/network-services.js)
[http] Request timeout on [https://duniter.ganut.fr/blockchain/current] after waiting 29311ms [http-services.js:45](https://moul.re/cesium/maps/dist_js/dist/dist_js/app/services/http-services.js)
[network] [#5] Started - 11 peer(s) found, in 30396ms [network-services.js:914](https://moul.re/cesium/maps/dist_js/dist/dist_js/app/services/network-services.js)
[network] [#5] BMA endpoint [g1.asycn.io] is EXCLUDED (incompatible version 1.9.0) [network-services.js:1097](https://moul.re/cesium/maps/dist_js/dist/dist_js/app/services/network-services.js)
[network] [#5] BMA endpoint [duniter.pini.fr] is EXCLUDED (incompatible version 1.9.0)
Quand on regarde sur Ǧinspecte ou sur Kazou on voit que c’est la catastrophe. La v1 est délaissée 
Pour moi, c’est ce qui explique la chute du nombre de membres. Les gens attendent la v2, à mon sens.
Perso, il faut également que je remette en place mon nœud miroir v1, qui s’est désynchronisé il y a fort longtemps.
3 Likes
L’un des problèmes c’est que lorsqu’on installe un noeud V1 il quasiment impossible de synchroniser jusqu’au bout peu importe la méthode… perso j’ai laissé tomber comme beaucoup d’autres… 
3 Likes
La G1 est en train de faire un arrêt cardiaque !!
mais on ne peut pas changer manuellement de noeud
Il faut arrêter de “croire des trucs” depuis “la tour d’ivoire des développeurs”.
Cet événement est juste révélateur de la fuite en avant technique de l’équipe de chirurgien qui ont décidé d’opérer une transplantation de cœur sur un corps qui n’est pas encore adulte (La G1 est un enfant de 7ans)
Je sais que son coeur (v1) a besoin de rester sous perfusion et surveillance… C’est le cas de tous système “pair à pairs” qui sont soumis à un moment ou un autre au problème de partitionnement (Théorème de CAP !!!)… J’ai un doute sur la capacité de la v2 à passer le “Mur du Son” (p2p gossip).
Vous verrez qu’il y a de multiples possibilités pour arriver à orchestrer le partitionnement… La technique est le stacking… On retrouve cela dans les jeux massivement multijoueurs, où les noeuds se partagent et s’occupent que d’un sous-ensemble de joueurs du même secteur.
En attendant de trouver l’ensemble protocolaire qui passe le mur du son… On pourrait améliorer facilité la re-synchronisation en permettant un import de DB à la main, on pourrait relier les noeuds dans un Virtual LAN (partage de clefs publiques = ssh), utiliser les “primo transactions” ou les interactions dans d’autres logiciels crypto (par exemple PGP, ou GChange) pour visualiser et disposer d’autres “toiles de confiance”…
L’objectif devrait être de stabiliser et d’améliorer progressivement le système existant, tout en préparant les évolutions futures, plutôt que de miser uniquement sur une V2 qui risque d’arriver trop tard.
Je ne suis pas développeur, je suis ingénieur en “Math Appliquées”… J’aime les système autonomes fiables et les UX agréables… SVP. Invitez moi aux prochaines réunions 
En attendant, état d’alerte maximum
j’espère qu’on va arriver à recoller rapidement “Cesium/Duniter”… J’ai mis la 1.6.12 sur IPFS /ipfs/QmcyboQUfjfLyCpVrXh7C8CZTGKkGST7Z53zCdD6SmiqGj/ (modif manuelle serveur duniter)
@cgeek @kimamila au secours …
Ce qui est difficile, c’est que tout le monde semble pointer des problèmes différents, donc pas facile de savoir ce qui est bloquant.
En effet le principal soucis que j’identifie, c’est que la Ğ1 est en train de se séparer en deux réseaux différents à cause de ces 3 lignes de code dans Cesium:
// CHeck version compatible, from min version
if (!peer.version || !csHttp.version.isCompatible(csSettings.data.minVersionAtStartup || csSettings.data.minVersion, peer.version) ||
// Exclude beta versions (1.9.0* and 1.8.7-rc*)
peer.version.startsWith('1.9.0') || peer.version.startsWith('1.8.7-rc')
) {
console.debug('[network] [#{0}] BMA endpoint [{1}] is EXCLUDED (incompatible version {2})'.format(data.pid, peer.getServer(), peer.version));
return false;
}
Etant donnée que G1nkgo ne se sert lui que des noeuds 1.9.0 pour GVA.
As-tu essayé avec un noeud Docker sur Duniter 1.9.0 ? La sync s’y passe beaucoup plus facilement que sur les version précédente. La v1.9.0 ne contient pas que GVA, mais également des patch réseaux effectués par Elois. C’est pour ça que la 1.9.0 a mis autant de temps à passer en prod, parcequ’elle contient en fait pas mal d’oxydation de certaines couches, et que Elois avait relevés des bugs avant d’officialiser la mise en prod, mais les bugs en questions sont déjà présent en 1.8.x.
@kimamila je suis d’avis de lever cette restriction 1.9.0 côté Cs, sauf si tu y vois un problème que je n’aurais pas identifié ?
Ca permettrait au scan réseau, en l’état, d’avoir plus de matière pour choisir un noeud valide.
Je vois du code traitant l’API GVA dans Cs, alors que cette API n’est pas utilisé dans l’app. (et que pour le moment les noeuds GVA sont tout bonnement rejetés de toute façon).
Tant que les nœuds communiquent entre-eux via une API compatible, la Ğ1 reste non-séparée en différents réseaux. Les clients peuvent communiquer avec deux API différentes sans poser réel problème, non ? Il y a cependant, un eu une bifurcation au niveau des versions 1.8.x et 1.9.x. La 1.9.0 n’a pas atteint l’état d’une version stable et la v1.8.x a continué d’évoluer en 1.8.7. La v1.9.0 n’a pas les optimisations BMA.
Bon à savoir, il faut que je teste cette version.
Il me semble que Benoît a exclus les API BMA des nœuds v1.9.0 de ces appels Cesium, surement, car elle n’implémente pas les optimisations qui ont mené à Duniter v1.8.7.
1 Like
Et oui, la vraie question est pourquoi ne pas avoir effectué les optimisations BMA directement à partir de 1.9.0.
Désormais, les conflits sont trop nombreux pour tester un rattrapage simple pour une v1.9.1:
29 fichiers en conflits avec parfois 10 conflits dans un fichier, ce n’est plus gérable.
Les différents clients sont donc condamnés à utiliser des noeuds Duniter différents.
edit: j’ai quand même réalisé un merge en tentant de régler tous les conflits ici, pour une version 1.9.1 donc: Files · release/1.9.1 · nodes / typescript / duniter · GitLab
mais je n’ai pas testé, car je n’ai pas l’environnement de dev pour. Il faudrait lancer tous les tests, mais ya de bonnes chances que ça pète quelque part.
Si ca fonctionne on pourrait mettre à jour Cesium pour n’exclure que les noeud 1.9.0 mais autoriser les 1.9.1 qui contiennent les optimisations BMA.
Car en testant localement de ne plus exclure les noeud 1.9.0, le scan réseau se déroule beaucoup mieux.
1 Like
Note : j’ai laissé mon message en suspend sans l’avoir publié.
Benoît a également porté ces optimisations BMA sur la branche dev qui est-elle même basée sur la branche release/1.9. Donc, c’est rattrapable. Il est possible de faire une autre release 1.9 avec les optimisations BMA sur la v1.9.
Par contre, se pose les questions d’officialiser la v1.9 comme stable et de la maintenir. Ne sachant pas ce qu’il s’est passé. Il n’y a pas de changelog et l’être qui les a développés n’est plus-là.
J’ai pu construire l’image Docker à partir de la branche dev avec la subtilité suivante :
duniter> podman build . -f release/docker/Dockerfile
Y’a-t-il une image publiée de la branche release/1.9 ? Je n’ai pas trouvé sur https://hub.docker.com/u/duniter.