C’est bon pour moi, j’avais plusieurs soucis dont – je pense – les propriétés de networks.
Disponible sur : https://gdev-indexer.cgeek.fr (indexation en cours)
Par contre pour mon installation qui est sur ARM, j’ai dû recompiler pour les images Docker. Et je devrais le faire à chaque mise à jour. Idéalement il faudrait le faire automatiquement avec la CI comme pour Duniter dont on peut s’inspirer (.gitlab-ci et Dockerfile). J’ai créé #144 pour ne pas oublier.
Tu n’a pas dû prendre la dernière version parce que là ton genesis est celui d’une chaîne de développement.
Et sinon l’issue devrait plutôt aller dans le dépôt de l’indexeur, non ?
Ah oui, j’étais sur master j’ai pensé que c’était la bonne sans vérifier. C’est corrigé.
Quant aux issues, oui en théorie. Mais c’est plus simple de tout centraliser dans le projet Duniter vu la petite taille des équipes et des moyens disponibles.
Salut,
Je tente à mon tour de monter une instance d’indexeur. Mais je suis bien incapable de vérifier que ça fonctionne correctement. Si quelqu’un veut bien jeter un oeil là : https://indexer-gdev.pini.fr.
EDIT: J’ai ce message d’erreur en boucle dans la log de duniter-indexer :
2023-12-16 22:46:55 RPC-CORE: getBlock(hash?: BlockHash): SignedBlock:: -32000: Client error: Api called for an unknown Block: State already discarded for 0xa565a0ccbab8e5f29f0c8a901a3a062d17360a4d4f5319d03a1580fba4cbf3f6
EDIT 2: Bon en fait mon noeud n’était pas en mode archive. Je le reconstruis, puis je relancerai l’indexeur avec suppression des données, voir si ça lui plaît mieux.
EDIT 3: Ça y est ça a l’air de marcher.
En examinant les logs de mon indexeur je trouve cette erreur intervenue probablement pendant la synchro :
node:internal/process/promises:288
triggerUncaughtException(err, true /* fromPromise */);
^
PostgresError: insert or update on table "identity" violates foreign key constraint "identity_id_fkey"
at ErrorResponse (file:///node_modules/postgres/src/connection.js:790:26)
at handle (file:///node_modules/postgres/src/connection.js:476:6)
at Socket.data (file:///node_modules/postgres/src/connection.js:315:9)
at Socket.emit (node:events:517:28)
at addChunk (node:internal/streams/readable:335:12)
at readableAddChunk (node:internal/streams/readable:308:9)
at Readable.push (node:internal/streams/readable:245:10)
at TCP.onStreamRead (node:internal/stream_base_commons:190:23)
at new Query (file:///node_modules/postgres/src/query.js:35:9)
at Object.sql (file:///node_modules/postgres/src/index.js:112:11)
at EventEmitter.<anonymous> (file:///build/assets/identity-83441b8c.mjs:53:20)
at EventEmitter.emit (node:events:517:28)
at processBlock (file:///build/assets/start-indexer-e0d1da9f.mjs:220:26)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async indexBlocks (file:///build/assets/start-indexer-e0d1da9f.mjs:289:15)
at async Timeout._onTimeout (file:///build/assets/start-indexer-e0d1da9f.mjs:363:7) {
severity_local: 'ERROR',
severity: 'ERROR',
code: '23503',
detail: 'Key (pubkey)=(5CQ8T4qpbYJq7uVsxGPQ5q2df7x3Wa4aRY6HUWMBYjfLZhnn) is not present in table "account".',
schema_name: 'public',
table_name: 'identity',
constraint_name: 'identity_id_fkey',
file: 'ri_triggers.c',
line: '2528',
routine: 'ri_ReportViolation',
query: '\n UPDATE identity SET "pubkey"=$1\n WHERE pubkey = $2\n ',
parameters: [
'5CQ8T4qpbYJq7uVsxGPQ5q2df7x3Wa4aRY6HUWMBYjfLZhnn',
'5GMyvKsTNk9wDBy9jwKaX6mhSzmFFtpdK9KNnmrLoSTSuJHv'
],
args: [
Builder {
first: {
oldPubkey: '5GMyvKsTNk9wDBy9jwKaX6mhSzmFFtpdK9KNnmrLoSTSuJHv',
pubkey: '5CQ8T4qpbYJq7uVsxGPQ5q2df7x3Wa4aRY6HUWMBYjfLZhnn'
},
rest: [ 'pubkey' ]
},
'5GMyvKsTNk9wDBy9jwKaX6mhSzmFFtpdK9KNnmrLoSTSuJHv'
],
types: [ 25, 25 ]
}
Oui, il y a des bugs dans l’indexation, c’est plus ou moins lié à ce sujet : ⚠ Relations circulaires compliquées. Le fix implémenté par Manu de trier les événements ne fonctionne pas toujours, je n’ai pas compris pourquoi. Comme subsquid est plus facile à débugger, je me fie plutôt à cet indexeur. Il va falloir qu’on fasse un choix à un moment mais pour l’instant on est dans une position inconfortable où les outils utilisent duniter-indexer (Ğecko, gecko-web, Ğcli) mais où les données les plus fiables sont sur duniter-squid.
Et c’est en travaillant sur duniter-squid que je me suis rendu compte de la galère que c’était de gérer tous les événements liés aux pending membership, d’où la réflexion À quoi servent les pending membership? qui a abouti à leur retrait (MR !215). Donc c’est normal que tout bouge encore sous nos pieds, c’est justement ça le travail de stabilisation ! (je le dis surtout pour les autres qui lisent ces messages parce que je me doute que tu le sais 
).
A tous ceux qui héberge un indexer Hasura (notamment @HugoTrentesaux, @cgeek et @Pini), pouvez-vous activer l’écoute websocket dans votre conf nginx svp ?
# for websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
Exemple pour ma conf datapod:
upstream gdev-datapod.p2p.legal {
server 10.10.10.107:10010;
}
[...]
location / {
proxy_pass http://gdev-datapod.p2p.legal;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header Host $http_host;
proxy_redirect off;
# for websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
C’est nécessaire pour utiliser des subscriptions GraphQL. Merci!
N’est-ce pas déjà le cas pour gdev-indexer.cgeek.fr ? J’ai la même conf que pour d’autres services qui fonctionnent déjà (notamment la webui de Duniter v1).
As-tu une URL que je peux tester pour vérifier ?
Via la console Hasura, tu peux faire des subscriptions, par exemple sur les datapod:
subscription {
profiles_by_pk(address: "5CQ8T4qpbYJq7uVsxGPQ5q2df7x3Wa4aRY6HUWMBYjfLZhnn") {
updated_at
}
}
N’importe quelle query peut se transformer en subscription.
Tu fais play et le bouton doit se transformer en bouton stop, si la requête initiale fonctionne c’est que WS est OK.
Je n’ai plus accès une console Hasura d’un indexer vue que le miens est HS, mais j’ai dû ajouter ça dans ma conf nginx pour datapod pour ws.
En fait le code que je fais dans gecko pour tenter une subscription ne fonctionne sur aucun de vos 3 indexer et moi j’en ai pas, donc je sais pas si le soucis vient de moi (probablement c’est la première fois que j’en fait en GraphQL) ou de votre conf nginx ^^
Non excuse moi j’étais pas clair, il s’agit d’une requête datapod et non indexer.
Voilà un exemple qui devrait fonctionner mais que je n’ai pas pu tester:
subscription ($address: String!) {
account_by_pk(pubkey: $address) {
transactions_issued(limit: 1) {
receiver_pubkey
amount
created_at
}
}
}
En fait n’importe quelle query classique tu remplaces le mot clé query par subscription avant la requête.
subscription {
account_by_pk(pubkey: "5CQ8T4qpbYJq7uVsxGPQ5q2df7x3Wa4aRY6HUWMBYjfLZhnn") {
transactions_issued(limit: 1) {
receiver_pubkey
amount
created_at
}
}
}
ok et surtout la requête initiale semble avoir fonctionner visiblement, donc c’est que tes websockets sont ok, donc je fais n’imp dans mon code 
Là regarde tu va voir la transaction changer dans 30 secondes
(voilà, si ton indexer fonctionne …)
Je vois rien bouger (*). Y’a pas une requête qui changerait à chaque bloc pour permettre de vérifier plus facilement ?
(*) Même en rechargeant la page et en relançant la requête.
EDIT: En fait c’est normal que ça bouge pas. C’est à cause du limit 1. Si je mets linit 2 ça m’affiche deux transactions, la première étant la plus ancienne. Il faut donc faire en sorte d’afficher la transaction la plus récente. Mais je ne sais pas faire.
Celle-ci j’imagine:
subscription MySubscription {
block(limit: 1, order_by: {number: desc}) {
created_at
}
}
Mais faut attendre la finalisation car l’indexer se cale uniquement sur les blocs finalisés.
Mais j’ai oublié un élément crutiale dans ma précédente requête, le order_by:
subscription {
account_by_pk(pubkey: "5CQ8T4qpbYJq7uVsxGPQ5q2df7x3Wa4aRY6HUWMBYjfLZhnn") {
transactions_issued(limit: 1, order_by: {created_at: desc}) {
receiver_pubkey
amount
created_at
}
}
}
La date devrait être aujourd’hui, sinon c’est que ton indexer n’est plus synchro.
En tout cas tes WS fonctionnent sinon tu aurais un icone de chargement dans la partie de droite au lieu de la réponse de la requête, donc c’est ce que je voulais savoir, merci 
ah oui t’es à jours, maintenant regarde dans moins de 30 secondes…
(voilà)
