<9E>Test"
[rpc-check] All checks passed
```
J’ai essayé de supprimer le volume et de relancer mais ca recommence à nouveau.
---
### Author:  [@Moul](https://forum.duniter.org/u/Moul)
#### Post date: [21 March 2026 15:21 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/25 "2026-03-21T15:21:23Z")
Oui, Squid n’est pas fonctionnel sur la ĞTest pour un lancement from scratch. C’est connu et pas corrigé.
> [@Indexeur Squid bloqué sur le même bloc](https://forum.duniter.org/t/indexeur-squid-bloque-sur-le-meme-bloc/13632/3):
>
> J’ai tenté…
---
### Author:  [@aya](https://forum.duniter.org/u/aya)
#### Post date: [21 March 2026 18:16 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/26 "2026-03-21T18:16:27Z")
Arf ok merci pour le pointeur je vais regarder ca.
---
### Author:  [@BulmAnanaBelle](https://forum.duniter.org/u/BulmAnanaBelle)
#### Post date: [24 March 2026 20:04 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/27 "2026-03-24T20:04:35Z")
Squid en cours d’indexation ! J’ai un peu galéré avec la mémoire, ça a planté plusieurs fois avant d’aboutir… J’ai fini par arrêter tous les docker de la machine pour ne lancer que l’archive et le squid pour qu’ils se calent sans cramer toute la mémoire.
Je reviens dans la forge 🙂
---
### Author:  [@Nicolas80](https://forum.duniter.org/u/Nicolas80)
#### Post date: [25 March 2026 19:35 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/28 "2026-03-25T19:35:18Z")
> [@poka](#):
>
> Dans la dernière version de gecko, j’ai passé le check min version squid à 0.5.13, tous les autres seront ignorés.
@poka je pense que cela bloque les squids en GTest non ?
A moins que l’on ait également une version 0.5.13 pour la GTest ? (je n’ai plus d’indexer en GTest donc je ne peux pas vérifier)
---
### Author:  [@BulmAnanaBelle](https://forum.duniter.org/u/BulmAnanaBelle)
#### Post date: [28 March 2026 18:23 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/29 "2026-03-28T18:23:25Z")
En effet, j’ai installé Squid en Gtest avec la dernière version disponible qui est la 0.5.11 donc elle n’est pas accepté par Gecko en Gtest 😭
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [28 March 2026 18:37 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/30 "2026-03-28T18:37:28Z")
Oui, c’est cassé pour la gtest, j’ai décrit ce qu’il faudrait faire ici pour faire une nouvelle image fonctionnelle :
> [@Indexeur Squid bloqué sur le même bloc (ĞTest)](https://forum.duniter.org/t/indexeur-squid-bloque-sur-le-meme-bloc-gtest/13632/23):
>
> J’ai pas trop de temps pour ça en ce moment ni envie de mettre la priorité dessus, mais voilà comment je ferais :
>
> - trouver les infos suivantes :
> - numéro de bloc de la Ǧ1v1 utilisé pour lancer la gtest
> - timestamp auquel a été lancé la commande “build chainspecs” pour la gtest
>
> - trouver une archive de Duniter v1 correspondant au bloc sur lequel a été démarrée la gtest
> - lancer py-g1-migrator dessus
> - lancer le “build chainspecs” de duniter en précisant le bon timestamp
> - intégrer les fichier de sortie dans une image squid
> - tester le démarrage
---
### Author:  [@Pini](https://forum.duniter.org/u/Pini)
#### Post date: [29 March 2026 13:31 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/31 "2026-03-29T13:31:36Z")
> [@poka](#):
>
> edit: dans votre .env squid je vous conseil fortement d’augmenter le rate limiter, moi je le passe de 300 à 3000 (sur 15 minutes), j’ai commit le fallback par defaut:
>
> `RATE_LIMIT_MAX_REQUESTS=3000`
Je viens de mettre à jour le `.env` pour mon indexeur, et j’ai redémarré les services avec `docker compose up -d`. Mais aucun conteneur n’a été mis à jour par cette action.
J’en conclus qu’il faut en plus citer explicitement ces variables dans le `docker-compose.yml` pour qu’elles soient prises en compte. Mais pour quel service ? Le `server` avec l’image `duniter/squid-graphile-g1` ?
EDIT: Sachant qu’on retrouve `rate_limit.js` dans les images Docker `squid-app` et `squid-graphile` j’ai ajouté les variables d’environnement `RATE_LIMIT_*` aux services `processor` et `server`.
---
### Author:  [@BulmAnanaBelle](https://forum.duniter.org/u/BulmAnanaBelle)
#### Post date: [17 June 2026 21:51 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/32 "2026-06-17T21:51:29Z")
Hello, j’ai voulu remettre en route mon squid Gtest et j’ai eu le même souci, j’ai demandé à Claude s’il pouvait s’occuper de faire passer l’indexation pour tester Gecko en Gtest.
Donc voilà, ça tourne sur mon serveur, reste à voir si ça abouti…
> [@Claude](#):
>
> @HugoTrentesaux merci pour la marche à suivre sur la reconstruction de la genèse
> GTest. En attendant d’avoir le temps de la refaire proprement, j’ai écrit un
> **patch pragmatique** qui empêche le processor de boucler sur les smiths absents,
> et il tourne maintenant sans souci sur la ĞTest du serveur de Bulmananabelle.
>
> **Le symptôme** (squid 0.5.13) : crash au bloc 48783 sur un `SmithMembers.SmithCertAdded`
> référençant le Smith index 12483 →
> `EntityNotFoundError: Could not find any entity of type "Smith" matching: { "index": 12483 }`
> → redémarrage Docker → re-crash → boucle infinie.
>
> **La cause** : la genèse GTest n’a chargé que 9 smiths en base, alors que des
> événements on-chain en référencent d’autres. L’identité 12483 existe bien, mais
> pas l’entité Smith correspondante.
>
> **Le correctif** : dans `src/data_handler.ts`, je remplace les `findOneByOrFail`
> sur les Smith par un helper qui crée un « smith fantôme » (rattaché à la vraie
> identité) quand il manque, et l’enregistre pour qu’il soit bien persisté avant
> le `smith_cert` (sinon la FK casse au flush). Si même l’identité manque, on
> ignore l’événement avec un warn plutôt que de planter. C’est dans l’esprit du
> `getOrCreateSmith` déjà présent et de la convention « skip + warn » déjà utilisée
> pour les validators.
>
> **Résultat** : le processor a franchi le bloc 48783 et indexe de nouveau la chaîne
> (smith 12483 + son cert créés, 0 erreur fatale). Les éventuels smiths manquants
> suivants sont gérés sans crash.
>
> J’ai ouvert le détail technique + le diff sur l’issue #66 :
> [Can’t start from zero on ĞTest (#66) · Issues · nodes / duniter-squid · GitLab](https://git.duniter.org/nodes/duniter-squid/-/work_items/66)
> Je peux proposer une MR si ça vous va. Évidemment ça ne remplace pas une vraie
> genèse complète, mais ça permet d’avoir un indexeur GTest fonctionnel tout de suite.
>
> — Claude
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [17 June 2026 22:55 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/33 "2026-06-17T22:55:59Z")
Chouette, hésite pas à faire une merge request avec le patch, ce sera plus facile pour travailler dessus. C’est ok pour la gtest de faire ça, mais il faudra pas fusionner ce code pour la Ǧ1 parce que c’est utile que l’indexeur crash s’il y a une vraie incohérence au niveau de forgerons, ça nous permet d’éviter de créer de la donnée incohérente et non sourcée en blockchain côté indexeur ce qui est un enfer à débugger (je travaille actuellement sur un projet d’indexeur décentralisé et traçable, mais ce n’est pas encore prêt à prendre le relais de squid, ce sera plutôt pour les données hors chaîne).
---
### Author:  [@BulmAnanaBelle](https://forum.duniter.org/u/BulmAnanaBelle)
#### Post date: [18 June 2026 21:00 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/34 "2026-06-18T21:00:23Z")
Hello, pour le moment, j’ai juste mis des commentaires de l’avancée de Claude sur mon serveur, il a dû faire d’autres ajustements. [Can’t start from zero on ĞTest (#66) · Issues · nodes / duniter-squid · GitLab](https://git.duniter.org/nodes/duniter-squid/-/work_items/66#note_53357)
Est-ce que ce ne serait pas plus simple de refaire une copie de la production pour mettre à jour la Gtest ? ou c’est galère ? ça tourne maintenant, même s’il y a bcp d’erreurs…
```auto
2026/06/18 10:55PM 3 ns=sqd:processor:mapping msg=Validator g1LbMawbCrzqnSyXEPczEUjDbmbUFqmdSBW4hCM5KAhY6f9Pr not found for block 713482, skipping forge count
2026/06/18 10:55PM 3 ns=sqd:processor:mapping msg=Validator g1PcEKFn1eRCn4h2hRmbuzFASJJZuap4H87KBd9cSHdWzK8LQ not found for block 713484, skipping forge count
2026/06/18 10:55PM 3 ns=sqd:processor:mapping msg=Validator g1PiFLg2KQAHJej733C8fbpoZLHuiusCXdKcSktDYs4vgYdVb not found for block 713488, skipping forge count
2026/06/18 10:55PM 3 ns=sqd:processor:mapping msg=Validator g1PkCwyp8cSjQfGrShybGjyzhfYgqD8hxJVoZWEHA7zTH7u8j not found for block 713489, skipping forge count
2026/06/18 10:55PM 2 ns=sqd:processor msg=713479 / 3598506, rate: 23 blocks/sec, mapping: 55 blocks/sec, 165 items/sec, eta: 35h 15m
2026/06/18 10:55PM 3 ns=sqd:processor:mapping msg=Validator g1PkCwyp8cSjQfGrShybGjyzhfYgqD8hxJVoZWEHA7zTH7u8j not found for block 713491, skipping forge count
2026/06/18 10:55PM 3 ns=sqd:processor:mapping msg=Validator g1PiFLg2KQAHJej733C8fbpoZLHuiusCXdKcSktDYs4vgYdVb not found for block 713493, skipping forge count
2026/06/18 10:55PM 3 ns=sqd:processor:mapping msg=Validator g1PcEKFn1eRCn4h2hRmbuzFASJJZuap4H87KBd9cSHdWzK8LQ not found for block 713496, skipping forge count
```
> [@Claude](#):
>
> ETA = “Estimated Time of Arrival” — le temps restant estimé avant que l’indexeur rattrape la tête de chaîne.
>
> Décodage de ta ligne :
>
> 713479 / 3598506 → bloc courant / bloc cible (tête de chaîne) = ~19,8 % indexé
> rate: 23 blocks/sec → vitesse globale (moyenne, écriture en base comprise)
> mapping: 55 blocks/sec → vitesse de traitement pur des blocs (avant I/O DB)
> 165 items/sec → débit d’événements/items traités
> eta: 35h 15m → à ce rythme, ~35 h pour atteindre les 3 598 506 blocs
>
> À noter : l’ETA fluctue selon le rate instantané (qui dépend de la densité d’events par bloc, des accès DB, de la charge serveur), donc c’est une
> estimation glissante, pas une échéance ferme. Plus tôt dans la session le rate montait à ~40-50 blocks/sec ; là il est à 23, d’où ~35 h affichées. La tête
> de chaîne avance aussi pendant ce temps (d’où la cible qui grimpe légèrement : 3,58 M → 3,598 M), mais l’indexeur rattrape bien plus vite que la chaîne
> ne progresse.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [19 June 2026 18:12 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/35 "2026-06-19T18:12:23Z")
On pourrait aussi relancer une gtest. Je n’ai pas tellement d’avis là dessus. Pour moi en ce moment seule la Ğ1 est importante, on ne fait pas assez de développements sur Duniter / Squid pour justifier de maintenir une Ğtest. Ma priorité est ailleurs en tout cas, j’espère pouvoir venir avec du concret sans trop tarder.
---
### Author:  [@BulmAnanaBelle](https://forum.duniter.org/u/BulmAnanaBelle)
#### Post date: [19 June 2026 22:30 UTC](https://forum.duniter.org/t/installez-squid-0-5-13/13745/36 "2026-06-19T22:30:51Z")
Ok, en attendant, je continue de tenter de refaire un squid… car je voudrais faire des tests en Gtest suite aux évolutions de Gecko. Bref, je suis puriste et j’ai plein de portefeuilles en Gtest 😆
Là, j’ai un souci avec mon noeud archive, du coup Claude va pointer sur le tien @HugoTrentesaux
> [@Claude](#):
>
> gtest.coinduf.eu (Hugo) │ renvoie la vraie valeur d’état du bloc fautif → vrai nœud ARCHIVE ✅✅
> ※ recap: Le squid GTest a été patché et indexait sans crash jusqu’au bloc 2,19M (61%), où il bloque maintenant à cause du nœud
> archive `duniter-archive-gtest` qui manque de l’état historique.
>
> > 🤖 Récap rédigé par Claude (assistant IA, via Claude Code), au nom de @BulmAnanaBelle.
>
> ## Bilan : indexer une ĞTest jusqu’au bout (patch résilient + nœud archive)
>
> En reprenant le processor Squid 0.5.13 bloqué en boucle sur ĞTest, deux problèmes
> distincts sont apparus.
>
> ### 1. Genèse incomplète → entités manquantes (corrigé côté squid)
>
> Le processor crashait sur `EntityNotFoundError` pour des entités référencées on-chain
> mais absentes de la base de genèse. Pas seulement les Smiths : en débloquant le 1er
> cas, j’ai rencontré successivement **3 types** d’entités manquantes :
>
> - `Smith` (index 12483, bloc 48783)
> - `Account` (g1MA9sr1…, bloc ~178357)
> - `Identity` (index 17337, bloc ~182381)
>
> → Patch « résilient » sur tous les `findOneByOrFail`/`findOneOrFail` portant sur des
> entités de genèse, dans l’esprit de la convention « skip + warn » déjà présente :
> création d’une entité de substitution quand c’est nécessaire pour les FK (smith/account
> fantôme rattaché à sa vraie identité, enregistré pour upsert AVANT les FK enfants),
> sinon `skip + warn`. Plus aucun crash entité ensuite.
>
> ### 2. Le nœud « archive » n’en était pas un (problème d’infra)
>
> À ~bloc 2,19M (61 %), nouveau crash mais cette fois **non lié au squid** :
> `RpcError 4003 — Trie lookup error: Database missing expected key` sur
> `state_getStorageAt`. Diagnostic via `system_syncState` :
>
> startingBlock: 3132749 ← la base ne commence qu’au bloc 3,13M
>
> Le nœud, pourtant lancé avec `DUNITER_PRUNING_PROFILE=archive`, avait été
> **synchronisé via snapshot/warp depuis le bloc 3,13M, pas depuis la genèse** — il ne
> possède donc aucun état historique avant ce point. ⚠ Piège à signaler : `archive`
> ne garde « tout l’état » que **depuis le point de départ du sync** , pas rétroactivement.
>
> → Contournement : repointage du squid sur un vrai nœud archive complet. Genèse ĞTest
> commune vérifiée (`0xd4586d7d…cc57a`). Testés :
>
> - `wss://gtest.coinduf.eu` (Hugo) → **vrai archive** , sert l’état manquant ✅
> - `wss://mirror-rpc.gtest-bn.brussels.ovh` (Nicolas80) → pruné (`State already discarded`) ❌
>
> L’indexation est repartie et avance vers la tête (~3,61M). Une fois le squid au-delà
> de 3,13M, il pourra repasser sur un nœud local (qui possède l’état à partir de là).
>
> ### À retenir pour la communauté
>
> - Le patch squid rend l’indexation **résiliente à une genèse incomplète** , mais les
> données produites comportent alors des trous (entités fantômes / events ignorés) :
> c’est un mode dégradé, pas un substitut à une genèse correcte.
> - Pour ré-indexer une ĞTest **depuis la genèse** , il faut un nœud **réellement
> full-archive synchronisé depuis le bloc 0** — un snapshot/warp ne suffit pas.
>
> Détail technique + diff sur l’issue #66. Je peux proposer une MR si l’approche convient.
>
> — Claude
[Previous page](https://forum.duniter.org/t/installez-squid-0-5-13/13745.md?page=1)