Probleme avec la Gtest qui n'est plus operationnelle

Chiara07 · 5 September 2026 20:28

Bonjour à tous,

En testant Ğecko ces derniers jours, je me suis heurtée à un mur : plus aucun
indexeur ne fonctionne sur la ĞTest, et impossible de tester quoi que ce soit
qui touche à la toile de confiance. En creusant, il apparaît que le réseau
lui-même est à l’arrêt depuis plusieurs mois.

Claude:

L’état des lieux, mesuré le 5 septembre 2026

Le réseau est gelé :

genèse de la ĞTest v2 : 11 octobre 2025, tête actuelle au bloc 4 733 609

dernière identité créée : bloc 2 759 824, soit il y a ~137 jours (vers
le 21 avril 2026)

dernière certification émise : même période

1 360 membres pour 17 186 identités, avec un filet continu d’évènements
Removal

Les indexeurs :

squid.gtest.coinduf.eu → 502

gt-squid.axiom-team.fr → 502

squid.gtest.bulma.sleoconnect.fr → fonctionne et suit bien la chaîne, mais
répond environ une fois sur trois, et annonce la version 0.5.11

Ce dernier point a son importance pour les clients : durt2 (la brique
blockchain de Ğecko) exige un indexeur en 0.5.13 minimum, donc le seul
indexeur ĞTest vivant était rejeté d’office. J’ai vérifié par introspection
que son schéma GraphQL est pourtant identique à celui d’un 0.5.13, à un champ près — aucun.

Une coquille au passage, au cas où d’autres clients auraient la même :
indexer.duniter.org était listé chez nous comme indexeur ĞTest, alors qu’il
indexe la Ğ1 (même tête de chaîne au bloc près que g1-squid.asycn.io).
Attention si vous vous fiez à cette liste — et attention aussi au fait que le
bloc de genèse ne permet pas de distinguer Ğ1 et ĞTest, les deux exposant le même hachage à cause de l’historique Ğ1v1 importé. Il faut comparer les têtes de chaîne (Ğ1 ≈ 2,6 M, ĞTest ≈ 4,7 M).

Mes questions

Est-il envisageable de relancer la ĞTest — remettre des indexeurs en
ligne, et surtout retrouver assez de membres actifs pour que les tests de
certification et d’adhésion redeviennent possibles ?

Ou vaut-il mieux en repartir sur une neuve, avec une toile de confiance
de départ pensée pour le test ?

Y a-t-il un autre réseau de test vivant que j’aurais manqué ? La gdev est-elle utilisable ?

Ce que je peux apporter

Je reçois un mini PC dans les prochains jours et je comptais en faire un nœud miroir. Je ne me sens pas de tenir un indexeur public fiable — nom de domaine, TLS, disponibilité, suivi des versions : c’est un engagement que je ne peux pas garantir seule. En revanche je veux bien héberger un nœud ĞTest en mode archive, et un indexeur secondaire si quelqu’un de plus aguerri veut bien m’épauler pour la mise en place.

@BulmAnanaBelle : deux choses qui aideraient tout de suite, indépendamment du reste —

pourrais-tu passer ton image en 0.5.13 ou plus ? Ça débloquerait Ğecko en mode automatique dès maintenant.

et si un jour j’héberge un indexeur secondaire, un pg_dump de ta base
m’éviterait de réindexer 4,7 M de blocs depuis la genèse.

Merci d’avance,
Chiara

BulmAnanaBelle · 8 September 2026 07:40

Message rédigé avec Claude (assistant IA d’Anthropic), au nom de @BulmAnanaBelle, à partir d’une enquête sur le GitLab Duniter et de notre expérience d’exploitation de l’indexeur ĞTest depuis juin 2026.

Claude:

Salut @Chiara07, merci pour cet état des lieux — il est juste, et il recoupe ce qu’on observe de notre côté depuis des mois. Je réponds point par point, et j’ajoute ce qu’on a appris en réparant l’indexeur ĞTest, parce que ça éclaire une partie du problème.

1. Pourquoi mon indexeur annonce 0.5.11 (et pourquoi ce n’est pas juste « une mise à jour à faire »)

J’ai regardé du côté de nodes/duniter-squid. Deux constats :

Il n’existe pas de tag 0.5.11. Les tags passent de 0.5.10 (3 mars) à 0.5.12 (5 mars). Le « 0.5.11 » que voit Ğecko vient donc d’un package.json bumpé sur un commit intermédiaire jamais taggé — ce qui est cohérent avec la manière dont les images sont produites (voir plus bas).

Aucun tag de la série 0.5.x n’a de pipeline réussi. 0.5.0, 0.5.1, 0.5.5, 0.5.6, 0.5.7, 0.5.8, 0.5.10, 0.5.12, 0.5.13 : tous en échec. Le dernier tag avec un pipeline vert est 0.4.11, en octobre 2025. L’image 0.5.13 dont parlait @cgeek a été poussée à la main, et l’annonce ne concernait que la Ğ1 et les smiths-v2.

Donc : il n’existe probablement pas d’image duniter/squid-app-gtest en 0.5.13. Il n’y a rien à docker pull. Ce n’est pas de la négligence de ma part, c’est un trou dans la chaîne de publication.

2. La bonne façon de produire cette image (et ce n’est pas chez moi)

En lisant docs/dev/g1-production-launch.md dans duniter-v2s, l’étape 11 décrit exactement le mécanisme :
cargo xtask release squid trigger-builds g1-1100 --rpc-url wss://…
Cette commande déclenche le pipeline CI de duniter-squid, qui télécharge les données genesis depuis la release réseau GitLab, récupère les métadonnées Substrate depuis un RPC vivant, puis build et pousse les trois images multi-arch (squid-app-*, squid-graphile-*, squid-postgres-*). La version des images = celle du package.json au moment du déclenchement.

Ce qui veut dire :

l’équivalent pour nous serait cargo xtask release squid trigger-builds gtest-1100 --rpc-url wss://gtest.coinduf.eu (le nœud archive de @HugoTrentesaux, le seul que je sache complet), depuis le tag 0.5.13 ;

ça demande un GITLAB_TOKEN avec accès à nodes/duniter-squid et le DOCKERHUB_TOKEN de l’orga — que je n’ai pas. @cgeek, @poka, @HugoTrentesaux : est-ce que l’un de vous peut déclencher ce build ? C’est probablement une demi-heure de travail, et ça règle le blocage de Ğecko pour tout le monde, pas seulement chez moi.

accessoirement, ça repasserait par une régénération de la genèse — et c’est là que ça devient intéressant.

3. Notre expérience : ce qu’il a fallu pour faire tourner un squid ĞTest

Résumé de trois mois, pour éviter à d’autres de refaire le chemin.

La genèse ĞTest embarquée dans l’image est incomplète. Le processor plantait en boucle au bloc 48783 (EntityNotFoundError: Smith index 12483), et une fois ce cas débloqué il a buté successivement sur des Account manquants (~bloc 178357) puis des Identity manquantes (~bloc 182381). Les trois types d’entités de genèse sont concernés. C’est l’issue #66, toujours ouverte.

Notre correctif : un patch « résilient » sur src/data_handler.ts, qui remplace tous les findOneByOrFail sur ces entités par des variantes non-faillibles — création d’entités fantômes pour les Smiths, skip + warn ailleurs, dans l’esprit de la convention déjà présente pour les validators manquants. Ça indexe, mais c’est un mode dégradé assumé : les données comportent des trous. Ce n’est pas un substitut à une genèse correcte.

Or l’annonce de la 0.5.13 disait précisément « corrige les genesis de l’image ». Si le pipeline est relancé proprement pour la ĞTest, mon patch devient probablement inutile. C’est l’argument principal pour passer par la CI plutôt que par un rebuild artisanal chez moi.

L’autre gros écueil : le nœud archive. Squid exige un nœud d’archive complet. Le mien ne l’était pas (rien avant le bloc 3,13M), ce qui a produit des Trie lookup error: Database missing expected key en pleine réindexation. On a rattrapé les 3,6M de blocs en s’appuyant sur wss://gtest.coinduf.eu, puis rebasculé en local pour le live. Un resync archive depuis la genèse, c’est de l’ordre de 280 Go et plusieurs jours. @Chiara07, c’est le point à anticiper sur ton mini PC : un nœud ĞTest « archive » complet n’est pas une petite machine.

Enfin, un détail utile à tous : le healthcheck GraphQL des images échouait silencieusement (curl absent de node:20-alpine, et localhost qui résout en IPv6 alors que le service n’écoute qu’en IPv4). Corrigé en amont via la MR !37, mergée. C’est peut-être une partie de ton « répond une fois sur trois ».

4. Le pg_dump

Oui, volontiers, sur le principe. Deux réserves à poser clairement :

ma base est celle du processor patché : elle contient des entités fantômes et des événements ignorés. Bâtir un indexeur public dessus, c’est propager le mode dégradé ;

si le point 2 aboutit (image 0.5.13 avec genèse régénérée), il vaudra mieux réindexer proprement que partir de ma base. Le dump reste utile comme solution d’attente ou pour du dev.

Dis-moi ce qui t’arrange, je peux préparer un pg_dump -Fc compressé.

5. Relancer, ou repartir sur une neuve ?

Mon avis, avec la réserve que je ne suis pas décisionnaire :

Techniquement, refaire une ĞTest est un chemin documenté, pas de la magie noire. Le processus de lancement réseau existe dans duniter-v2s (scripts/launch-network.sh, puis cargo xtask release network g1-data / build-runtime / build-specs / create, puis la release client et le build squid). Il y a même de quoi lancer une chaîne gtest locale à deux autorités (gtest_local2, scripts/run-gtest-local2.sh) pour répéter la manœuvre sans risque. À adapter pour la ĞTest, évidemment — et il faudrait confirmer que launch-network.sh accepte bien --runtime gtest.

Le vrai obstacle n’est pas technique, il est social : il faut 3 à 5 forgerons engagés à tenir leur nœud, et surtout une toile de confiance de départ avec assez de membres actifs pour que tester certification et adhésion ait un sens. C’est exactement ce qui manque à la ĞTest actuelle : 1 360 membres pour 17 186 identités, et plus une seule certification depuis avril. Relancer les indexeurs sur une chaîne où personne ne certifie ne réglera pas ton problème de test de la toile.

Donc je pencherais pour : débloquer l’indexeur maintenant (point 2, c’est rapide et ça sert immédiatement), et ouvrir en parallèle la discussion sur une ĞTest neuve avec une genèse pensée pour le test — quelques dizaines d’identités bien connectées, des paramètres accélérés — plutôt que de s’acharner sur une chaîne gelée dont la genèse est de toute façon cassée.

6. Et Dunipod ?

À prendre en compte avant d’investir beaucoup d’énergie dans un squid ĞTest : @elois développe Dunipod, dont le microservice onchain-indexer remplace Squid, ne nécessite pas de nœud d’archive (un miroir minimal suffit) et permet de plafonner l’espace disque avec élagage automatique. C’est exactement la contrainte qui rend un indexeur ĞTest pénible à héberger aujourd’hui.

@elois : est-ce que Dunipod gère (ou pourrait gérer) la ĞTest, ou seulement la Ğ1 pour l’instant ? Si oui, @Chiara07 a peut-être intérêt à monter un pod plutôt qu’un squid, et la question du pg_dump disparaît d’elle-même.

Et pour Ğecko, la question devient : est-ce que durt2 pourrait accepter un pod Dunipod comme source alternative à un squid ?

En résumé : je veux bien mettre à jour mon image, mais l’image n’existe pas — il faut relancer le pipeline. Je peux fournir un dump en attendant. Et je pense qu’il faut poser sérieusement la question d’une ĞTest neuve, parce que le problème de fond n’est pas l’indexeur.

— BuLmA (@BulmAnanaBelle)

Chiara07 · 8 September 2026 08:29

Donc c’est pas gagné !
Je vais tester en vrai l’invitation, sur un portefeuille test, en espérant que l’option refuser fonctionne !

Mais en effet si il y a des dunipod dans les cartons prévoir une nouvelle Gtest neuve.

Merci de ta réponse @BulmAnanaBelle

elois · 10 September 2026 13:56

Oui j’ai ajouté le support de la ĞTest sur la version v0.10.0 de Dunipod:

J’héberge moi-même une instance dunipod sur la ĞTest, n’hésitez pas à la tester:

https://gtpod.elo.tf/v1/graphiql

Chiara07 · 10 September 2026 14:33

j’ai activé en Gtest ton noeud

par contre la base ne me reconnait pas comme membre non plus

Claude va me faire un serveur local sur mon minipc pour tester ce qui est relatif aux invitations et certifications

apres tu pourras me dire dans quelle mesure tu as besoin de tests ?
mais il faudrait une base recente

**
la recherche , l’activité, l’etat de membre ne fonctionnent pas

par contre la messagerie, le profil , le pseudo portefeuille fonctionnent

en mode G1

cela reconnaît mon etat de membre mais pas mon identité

et dans l’activité cela donne celle de la Gtest au lieu de G1

n’affiche aucune certification

elois · 10 September 2026 14:55

Déjà, commencer par tester que les données fournies correspondent à ce qui est attendu, ce que tu as déjà commencé à faire finalement

C’est une base récente, mon dunipod GTest est à jour sur la chaîne GTest, je viens de vérifier.

Ce qui te ferait croire que ce n’est pas à jour est plutôt une différence entre les données observées et ce à quoi tu t’attends. C’est peut-être un bug. Il faudrait me préciser l’écart entre ce à quoi tu t’attends et ce que tu observes, ainsi que la requête concernée, pour que je puisse investiguer.

Attention, chaque instance dunipod est mono-réseau. En mode G1, il faut requêter une instance G1 :

https://g1pod.elo.tf/v1/graphql
https://g1pod2.elo.tf/v1/graphql

Chiara07 · 10 September 2026 15:00

c’est que je ne suis pas membre dessus !

pour la G1 en effet cela marche mieux pour mon identité et mes certifications
par contre activité non reconnue

retour en Gtest

toujours pas membre et pas d’identité

pour l’activité pas de connexion !

elois · 10 September 2026 15:00

Quelle es ta clé membre sur gtest?

Chiara07 · 10 September 2026 15:07

g1NX2GZB3DgTMjDFRvZZbREQXcnZ11CRapzs2YKLSV1fnWy9z

je ne vois pas de difference avec mon adresse g1

g1NX2GZB3DgTMjDFRvZZbREQXcnZ11CRapzs2YKLSV1fnWy9z

elois · 10 September 2026 15:21

Ce compte n’a jamais été membre du réseau GTest actuel. J’ai vérifié sur tous les RPC Duniter listés dans https://git.duniter.org/nodes/networks/-/blob/master/gtest.json.

Chiara07 · 10 September 2026 15:49

ah ben oui puisqu’il y a eu la bascule en fait donc ce n’est plus la meme adresse

comment faire alors ? mon ancien compte membre qui a fait les tests a ete migré et je ne peux plus l’ouvrir avec gecko

elois · 10 September 2026 16:33

Ce n’est pas très précis. Prends l’habitude de demander à Claude ce que renvoient les requêtes GraphQL afin qu’il puisse déterminer si le problème vient de Dunipod ou de Gecko.

J’ai investigué de mon côté, et l’erreur sur la page d’activité du compte cache au moins trois bugs dans Gecko, Dunipod fourni bien les données attendues via GraphQL. J’ai ouvert des issues GitLab :

Il n’y a jamais eu de bascule sur la GTest, ou alors je ne comprends pas de quoi tu parles.

Pour tes tests, tu peux simplement demander à un membre de la GTest de t’inviter pour devenir membre. En revanche, ce serait plus prudent de créer un compte dédié à la GTest qui n’a pas le même mnemonic que ton compte G1.

Si tu m’indique un compte à inviter je peux le faire depuis mon compte membre gtest.

Chiara07 · 10 September 2026 17:15

Claude est bloqué jusque demain matin !
et comme je travaillais sur d’autres problemes je retiens ce que tu me dis
pour travailler sur la Gtest dans Gecko

le compte membre que j’avais utilisé lors des tests a l’automne dernier
g1MFgNDq5uqEsxvpoU2tAxR2Nf2WWmA7HmJe2z5nyJzobo7Zp
a migré depuis !

un portefeuille en gtest avec 2Gt dessus
g1Lov6pXBuUtwP3TJBAbJYQBTSXU5LxTQheFGSHi8jqA6yfiE

comment savoir qui a un compte Gtest ?

elois · 10 September 2026 17:33

D’accord, pas de souci, merci pour tes tests en tout cas

Ce compte a migré vers l’adresse g1P5ovLSTM4czQWXaSYTdgfyxaaLYRExrY9ViJcnGaDxTdarj, actuellement membre sur gtest. Peux-tu retrouver le mnemonic derrière ce compte ? Sinon, ce n’est pas grave, tu peux juste te faire certifier sur un nouveau compte.

Tu veux que je t’invite sur g1Lov6pXBuUtwP3TJBAbJYQBTSXU5LxTQheFGSHi8jqA6yfiE ?

Tu veux dire un compte membre ou un compte tout court ? La source de vérité, ce sont les RPC Duniter. Tu peux demander à une IA de les requêter ; en général, elle sait le faire. Sinon, tu peux passer par DuniterPortal : Duniter Portal

Côté Dunipod, tu peux lancer une requête GraphQL à la main via le dashboard GraphiQL :

Requête pour savoir si un compte est membre :

query {
  identities(filter: {
    accountId: { equalTo: "ADRESSE" }
  }) {
    nodes {
      isMember
    }
  }
}

Chiara07 · 10 September 2026 17:45

oui je l’ai ! un vieux fichier de tests non effacé !

merci merci

Chiara07 · 11 September 2026 11:49

ok on etait justement en train de travailler sur une partie de ce que tu as noté :

Claude:

#251 concerne ma MR !158, qui n’est pas encore fusionnée — et c’est important : en l’état, elle remplace un message faux par un autre message faux. Hier, un échec de chargement affichait « rien à afficher » ; avec !158 il affiche une erreur, donc « L’indexeur est indisponible » — alors que dans le cas de #249 l’indexeur répond parfaitement, c’est le nœud RPC qui ne sait plus dater le bloc 1. Il faut typer l’erreur, exactement dans l’esprit de ce qu’on a fait hier : ne pas affirmer une
cause qu’on ne connaît pas.

#249 décrit le chemin de code que !158 corrige à moitié : Elois écrit lui-même que « _loadItemsInner convertit ce résultat nul en historique vide, sans erreur ». On a corrigé ça hier sans savoir qu’il l’avait trouvé en parallèle. Mais la cause racine est en amont — la date de genèse lue sur le bloc 1, que les RPC élagués ont jetée.

on commence par #250 (du plus facile au plus lourd )

[EDIT]

bon ben on est tombé sur un bec d’où les problèmes rencontrés !

Claude:

Deux découvertes à remonter à poka, que nous n’aurions pas faites sans cette tentative :

La chaîne de génération de code de durt2 est cassée dans cette configuration.
L’override analyzer ^9.0.0 — que le dépôt s’impose pour résoudre ses dépendances face au meta du SDK Flutter — est incompatible avec dart_style comme avec json_serializable récents. Tant que ça dure, aucune requête GraphQL ne peut être modifiée dans durt2. C’est ce qui nous a forcés à plafonner plutôt qu’à paginer.

dart format sur durt2 reformaterait 583 fichiers : le dépôt n’est plus conforme au formateur actuel. J’ai donc évité de formater, pour ne pas noyer le correctif dans du bruit — mais c’est une dette qui gênera toute contribution.

transmis deja a @poka ! et issue ouverte sur durt2

#251 ok MR !158

pour la suite faut attendre la disponibilité de Claude, pas avant demain soir !

Chiara07 · 12 September 2026 15:39

#249 en cours de traitement
verdict

Claude:

@elois avait raison sur la cause, mais le vrai scandale est ailleurs : dans
l’historique, cette date de genèse ne servait à rien — sauf à dessiner la bannière «
début de la blockchain ». Chaque transaction porte déjà son propre
horodatage. Tout l’historique d’un compte était jeté pour une décoration.

Et c’était pire que l’écran vide : l’état vide était réécrit dans le cache. Chaque
tentative sur un nœud élagué effaçait l’historique local.

Trois choses corrigées

L’historique ne dépend plus de cette date. Même si nœud et indexeur se taisent,
les transactions s’affichent.

Là où elle compte vraiment (certifications, migrations : elles portent des
numéros de blocs), elle est cherchée auprès de l’indexeur puis retenue. Les 5
indexeurs sondés s’accordent à la seconde près, sur Squid comme sur Dunipod.
Requête écrite à la main → rien à publier côté durt2, le codegen cassé ne bloque
pas.

Deux bugs trouvés en chemin : l’activité réseau marquait toutes les transactions
comme venant de la Ğ1v1 (sentinelle DateTime(2099) faisant l’inverse de son
commentaire), et deux autres écrans renonçaient à leur fonction pour la même date
décorative — l’analyse de marché et la notification de paiement reçu.

L’audit a rattrapé du sérieux

Un bloquant que j’avais laissé passer : un ref.watch après un await. Passé un await,
le Ref peut être démonté et watch lève — exactement le piège Riverpod 3 déjà
consigné dans ce projet, et sur le chemin même que je réparais.

Plus grave sur le fond : je ne validais que le plancher de la date. Une genèse
repoussée dans le futur repousse toutes les dates d’expiration de certification, et
l’alerte « votre adhésion va expirer » ne se déclencherait plus jamais — sans rien
pour la contredire sur la ĞTest. Plafond ajouté.

Enfin, l’audit a corrigé une erreur dans mes propres notes : je croyais que Ğ1 et
ĞTest partageaient le même hachage de genèse. C’est faux, ils sont bien distincts.
J’ai rectifié la mémoire.

[edit] les corrections du texte de claude apres les audits

BulmAnanaBelle · 17 September 2026 22:00

Hello, ça bouge pour la Gtest @Chiara07 ! J’ai relancé le squid même si on va avoir le dunipod Première version "stable" de dunipod: v0.10.0 - #15 by BulmAnanaBelle qui arrive aussi… Dis-moi si besoin de tests en particulier, j’ai encore mes comptes de Gtest.
Il y a aussi le panel que j’ai amélioré Duniter panel, un client pour tester la v2 - #29 by BulmAnanaBelle

Chiara07 · 18 September 2026 05:18

Alors en Gtest maintenant c’est opérationnel sur gecko, par contre il va falloir faire des tests sur césium.
Je regarde sur mon PC car il faudra

tester un nouveau compte pour passer le cap des 5 certifs, donc se focaliser sur 1 compte piur le faire passer membre.

Et aussi tester une adhesion expirée voir si on arrive a certifier, et en Gtest on est tous repassé a zéro certifs pour les comptes réels, donc rechercher si on trouve notre bonheur.

Je pense m’y remettre cet aprem, je profite de la matinée pour jardiner a l’ombre.

Chiara07 · 18 September 2026 07:11

j’ai ce compte que je viens d’inviter

g1QPxAVGDJJzRk2KYkWdic38zVpmbZHGe33Miuwr5tKf5pGuR

ChiaraTest12sept

il faudrait le certifier en Gtest pour voir si il passe le cap des 5 certtifications et devient membre

actuellement c’est ce qui bloque(ait)

il faudrait voir aussi si on trouve un compte qui a perdu son adhesion par manque de certifications en Gtest pour le certifier

sinon essayer en normal

A noter que sur Gecko Gtest le reseau identité et certifications n’affiche rien !

alors que paola vient de certifier qq en Gtest et moi j’ai invité il y a 6 jours