Démarrez votre indexeur (tutoriel)

Nodes Indexers
1

Pour le dernier réseau gdev, j’avais rédigé un tutoriel pour démarrer un indexeur : Duniter | Run an indexer

Aujourd’hui j’aimerais avoir des retours pour améliorer ce tutoriel, et si possible des contributions directes.

Quelques modifications :

  • utiliser l’image h30x/duniter-indexer en attendant que la CI soit validée et les améliorations mergées dans master
  • vérifier la présence du network default dans le docker-compose.yml (cf Mise en production de l'indexeur, j’ai mis à jour la doc)

Avec les insertions par batch, l’indexeur devrait être beaucoup plus rapide à démarrer. Les logs sont écrits dans un fichier dédié dans le volume logs. On y voit notamment

  • les événements non pris en charge
# Unhandled event: account.AccountLinked
{"level":40,"time":1700575226062,"pid":1,"hostname":"d1bb47d605b6","msg":"[30801] Unhandled event: account.AccountLinked"}
  • les erreurs
# ici l'indexeur tente d'ajouter la transaction avant le nouveau compte, c'est un bug
{"level":50,"time":1700572081106,"pid":1,"hostname":"d1bb47d605b6","err":{"type":"PostgresError","message":"insert or update on table \"transaction\" violates foreign key constraint \"transaction_receiver_id_fkey\"","stack":"PostgresError: insert or update on table \"transaction\" violates foreign key constraint \"transaction_receiver_id_fkey\"\n    at ErrorResponse (file:///node_modules/postgres/src/connection.js:790:26)\n    at handle (file:///node_modules/postgres/src/connection.js:476:6)\n    at Socket.data (file:///node_modules/postgres/src/connection.js:315:9)\n    at Socket.emit (node:events:517:28)\n    at addChunk (node:internal/streams/readable:335:12)\n    at readableAddChunk (node:internal/streams/readable:308:9)\n    at Readable.push (node:internal/streams/readable:245:10)\n    at TCP.onStreamRead (node:internal/stream_base_commons:190:23)\n    at new Query (file:///node_modules/postgres/src/query.js:35:9)\n    at Object.sql (file:///node_modules/postgres/src/index.js:112:11)\n    at EventEmitter.<anonymous> (file:///build/assets/transaction-21260075.mjs:13:22)\n    at EventEmitter.emit (node:events:517:28)\n    at processBlock (file:///build/assets/start-indexer-e0d1da9f.mjs:220:26)\n    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at async indexBlocks (file:///build/assets/start-indexer-e0d1da9f.mjs:289:15)\n    at async file:///build/assets/start-indexer-e0d1da9f.mjs:346:7","name":"PostgresError","severity_local":"ERROR","severity":"ERROR","code":"23503","detail":"Key (receiver_pubkey)=(5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz) is not present in table \"account\".","schema_name":"public","table_name":"transaction","constraint_name":"transaction_receiver_id_fkey","file":"ri_triggers.c","line":"2463","routine":"ri_ReportViolation","query":"INSERT INTO transaction (\"issuer_pubkey\",\"receiver_pubkey\",\"amount\",\"created_at\",\"created_on\")values($1,$2,$3,$4,$5)","parameters":["5DSF5HxiQvy2xJdtdtMSPYZdSoLAsGDxzJaifiAfAByinrH4","5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz","5000","2023-11-21T13:07:48.002Z","30277"],"args":[{"first":{"issuer_pubkey":"5DSF5HxiQvy2xJdtdtMSPYZdSoLAsGDxzJaifiAfAByinrH4","receiver_pubkey":"5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz","amount":5000,"created_at":"2023-11-21T13:07:48.002Z","created_on":30277},"rest":[]}],"types":[25,25,700,1184,23]},"msg":"insert or update on table \"transaction\" violates foreign key constraint \"transaction_receiver_id_fkey\""}
{"level":40,"time":1700572081107,"pid":1,"hostname":"d1bb47d605b6","msg":"[30277] Insert account 5Dq8xjvkmbz7q4g2LbZgyExD26VSCutfEc6n4W4AfQeVHZqz"}

Pour info les logs

relation "parameters" does not exist

signifient qu’un nouveau bloc est finalisé sur le réseau mais que l’indexeur n’a pas encore fini d’indexer le genesis

et les logs

Already indexing.

signifient qu’un nouveau bloc est finalisé sur le réseau mais que l’indexeur est en train de rattraper son retard.

2

Pourrais-tu publier ton docker-compose.yml à jour ? Ou un fichier équivalent, car là j’ai beau essayer je n’arrive pas à lancer d’indexeur.

En fait je n’arrive même pas à faire démarrer Hasura.

3

Voilà le docker-compose qui tourne actuellement sur mon serveur :

détail 
services:
  # postgres database
  postgres:
    image: postgres:12
    restart: always
    volumes:
      - postgres-data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: xxx

  # hasura
  graphql-engine:
    image: duniter/hasura-indexer:latest
    depends_on:
      - postgres
    restart: always
    ports:
      - 127.0.0.1:8484:8080 # 8080 already used by wotwizard
    environment:
      # postgres database
      HASURA_GRAPHQL_DATABASE_URL: postgres://postgres:xxx@postgres:5432/postgres
      # enable the console served by server
      HASURA_GRAPHQL_ENABLE_CONSOLE: "true"
      # dev mode
      HASURA_GRAPHQL_DEV_MODE: "false"
      # logging
      # HASURA_GRAPHQL_ENABLED_LOG_TYPES: startup
      # admin password
      HASURA_GRAPHQL_ADMIN_SECRET: hasura_password
      # Name of role when the Authorization header is absent in JWT
      HASURA_GRAPHQL_UNAUTHORIZED_ROLE: public
      # telemetry
      HASURA_GRAPHQL_ENABLE_TELEMETRY: "false"
      HASURA_GRAPHQL_MIGRATIONS_SERVER_TIMEOUT: 60

  # indexer (must have duniter-archive on duniter network)
  indexer:
    image: h30x/duniter-indexer
    environment:
      - POSTGRES_HOST=postgres
      - INDEXER_DUNITER_WS_ENDPOINT=ws://duniter-archive:9944
      - INDEXER_DUNITER_WS_ENDPOINT_GRAPHIQL=wss://gdev.coinduf.eu/ws
      - INDEXER_HASURA_GRAPHQL_ENDPOINT_GRAPHIQL=https://hasura.gdev.coinduf.eu
    restart: unless-stopped
    ports:
      - 127.0.0.1:3000:3000
    depends_on:
      # - duniter-archive # depends on archive node through network
      - postgres
      - graphql-engine
    volumes:
      - logs:/logs
      - resources:/resources
    # allows to connect to duniter node
    networks:
      - default
      - duniter

# define volumes
volumes:
  postgres-data:
  logs:
  resources:

# define duniter external network to allow connect to duniter archive node
networks:
  duniter:
    name: duniter-gdev-archive_default
    external: true

(j’allais justement arrêter de bosser, tu arrives pile au bon moment)

4

Merci, mais il doit manquer quelque chose. Voici les logs que j’avais hier soir et que j’ai encore ce matin :

2023-11-22 08:00:23 {"timestamp":"2023-11-22T07:00:23.000+0000","level":"info","type":"startup","detail":{"kind":"migrations-startup","info":"migrations server port env var is not set, defaulting to 9691"}}
2023-11-22 08:00:23 {"timestamp":"2023-11-22T07:00:23.000+0000","level":"info","type":"startup","detail":{"kind":"migrations-startup","info":"server timeout is not set, defaulting to 30 seconds"}}
2023-11-22 08:00:23 {"timestamp":"2023-11-22T07:00:23.000+0000","level":"info","type":"startup","detail":{"kind":"migrations-startup","info":"starting graphql engine temporarily on port 9691"}}
2023-11-22 08:00:23 {"timestamp":"2023-11-22T07:00:23.000+0000","level":"info","type":"startup","detail":{"kind":"migrations-startup","info":"waiting 30 for 9691 to be ready"}}
2023-11-22 08:00:55 {"timestamp":"2023-11-22T07:00:55.000+0000","level":"info","type":"startup","detail":{"kind":"migrations-startup","info":"failed waiting for 9691, try increasing HASURA_GRAPHQL_MIGRATIONS_SERVER_TIMEOUT (default: 30)"}}

Peux-tu essayer sur une machine “neuve” ? Je me demande si tu ne réutilises pas des volumes pré-existants avec des données dedans que moi je n’ai pas.

Édit : ah, tiens, j’ai un résultat positif sur une autre machine. C’est encourageant.

5

J’ai bien supprimé les volumes avant de les recréer, et je le fais régulièrement en mode dev. Mais bonne idée, je ferai sur une machine neuve comme le “tuto d’installation en moins de 10 minutes”.

Par rapport à tes logs :

migrations server port env var is not set, defaulting to 9691

Étrange, parce que le serveur de migration c’est la base postgres si je me trompe pas et son port est défini à 5432. C’est drôle parce qu’avec une recherche sur “port 9691”, je tombe justement sur une issue hasura à ce sujet : Auto-apply migrations/metadata version breaks the app · Issue #5172 · hasura/graphql-engine · GitHub. Ça l’air un peu spécifique comme bug.

Et ensuite c’est les conséquences d’avoir le mauvais port. Donc il faut trouver la variable d’environnement responsable et lui donner une valeur.

Donc oui, possible qu’une autre machine fasse l’affaire.

6

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.

7

image
image2015×1148 128 KB

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 ?

8

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.

1 Like