// shoud never fail because destination of transfer must be existing account or raise System.NewAccount
const toAccount = await this.getAccountByAddressOrFail(ctx, transfer.to);
→
processor-1 | {"level":5,"time":1772608875654,"ns":"sqd:processor","err":{"stack":"EntityNotFoundError: Could not find any entity of type \"Account\" matching: {\n \"id\": \"g1K8FRGreTEqB7DH5tWpQWEA75iMWT8dg1UcSoYuU5oWQr1fk\"\n}\n at /squid/node_modules/.pnpm/typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2/node_modules/typeorm/entity-manager/EntityManager.js:682:39\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async StoreWithCache.findOneByOrFail (/squid/node_modules/.pnpm/@belopash+typeorm-store@1.5.0_@subsquid+typeorm-config@4.1.1_typeorm@0.3.26_ioredis@5.7_0562d5ed8c2d447272b97a9e909772f4/node_modules/@belopash/typeorm-store/lib/store.js:153:21)\n at async DataHandler.processNewData (/squid/lib/data_handler.js:86:31)\n at async /squid/lib/main.js:91:9\n at async TypeormDatabaseWithCache.performUpdates (/squid/node_modules/.pnpm/@belopash+typeorm-store@1.5.0_@subsquid+typeorm-config@4.1.1_typeorm@0.3.26_ioredis@5.7_0562d5ed8c2d447272b97a9e909772f4/node_modules/@belopash/typeorm-store/lib/database.js:45:13)\n at async /squid/node_modules/.pnpm/@subsquid+typeorm-store@1.5.1_@subsquid+big-decimal@1.0.0_typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2_/node_modules/@subsquid/typeorm-store/lib/database.js:84:13\n at async EntityManager.transaction (/squid/node_modules/.pnpm/typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2/node_modules/typeorm/entity-manager/EntityManager.js:75:28)\n at async TypeormDatabaseWithCache.submit (/squid/node_modules/.pnpm/@subsquid+typeorm-store@1.5.1_@subsquid+big-decimal@1.0.0_typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2_/node_modules/@subsquid/typeorm-store/lib/database.js:164:24)\n at async Runner.withProgressMetrics (/squid/node_modules/.pnpm/@subsquid+util-internal-processor-tools@4.2.1/node_modules/@subsquid/util-internal-processor-tools/lib/runner.js:217:22)","criteria":{"id":"g1K8FRGreTEqB7DH5tWpQWEA75iMWT8dg1UcSoYuU5oWQr1fk"},"message":"Could not find any entity of type \"Account\" matching: {\n \"id\": \"g1K8FRGreTEqB7DH5tWpQWEA75iMWT8dg1UcSoYuU5oWQr1fk\"\n}"}}
J’ai tenté de mettre à jour indexer.duniter.org en v0.5.11.
Sans avoir supprimé le volume, c’est resté bloqué sur le même bloc.
Du coup, j’ai supprimé le volume, redémarré. Maintenant, j’ai cette erreur :
{"level":5,"time":1772614619028,"ns":"sqd:processor","err":{"stack":"Error: ENOENT: no such file or directory, open '/squid/input/block_hist.json'
En attendant j’ai arrêté le service (502), le temps que ça soit corrigé. Autant avoir un serveur qui répond une erreur qu’un serveur désynchronisé/bloqué.
Ok, en fait j’ai l’erreur suivante sur une installation fraîche :
{"level":5,"time":1772630490899,"ns":"sqd:processor","err":{"stack":"EntityNotFoundError: Could not find any entity of type \"Smith\" matching: {\n \"index\": 12483\n}\n
Qui est l’identité de vjrj.
Je retente sur un volume frais pour voir si je reproduis.
Mar 04 15:42:44 kepler docker-indexer-processor-start[2019656]: {"level":2,"time":1772638964880,"ns":"sqd:processor:mapping","msg":"48783 SmithMembers.SmithCertAdded"}
Mar 04 15:42:44 kepler docker-indexer-processor-start[2019656]: {"level":5,"time":1772638964885,"ns":"sqd:processor","err":{"stack":"EntityNotFoundError: Could not find any entity of type \"Smith\" matching: {\n> \"index\": 12483\n}\n at /squid/node_modules/.pnpm/typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect […coupé]
Mar 04 15:42:44 kepler systemd[1]: docker-indexer-processor.service: Main process exited, code=exited, status=1/FAILURE
J’ai tenté de lancé en v0.5.5, j’ai cette erreur (tel remonté dans ce post) :
{"level":5,"time":1772703362582,"ns":"sqd:processor","err":{"stack":"EntityNotFoundError: Could not find any entity of type \"Account\" matching: {\n \"id\": \"g1K8FRGreTEqB7DH5tWpQWEA75iMWT8dg1UcSoYuU5oWQr1fk\"\n}\n at /squid/node_modules/.pnpm/typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2/node_modules/typeorm/entity-manager/EntityManager.js:682:39\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async StoreWithCache.findOneByOrFail (/squid/node_modules/.pnpm/@belopash+typeorm-store@1.5.0_@subsquid+typeorm-config@4.1.1_typeorm@0.3.26_ioredis@5.7_0562d5ed8c2d447272b97a9e909772f4/node_modules/@belopash/typeorm-store/lib/store.js:153:21)\n at async DataHandler.processNewData (/squid/lib/data_handler.js:82:31)\n at async /squid/lib/main.js:85:5\n at async TypeormDatabaseWithCache.performUpdates (/squid/node_modules/.pnpm/@belopash+typeorm-store@1.5.0_@subsquid+typeorm-config@4.1.1_typeorm@0.3.26_ioredis@5.7_0562d5ed8c2d447272b97a9e909772f4/node_modules/@belopash/typeorm-store/lib/database.js:45:13)\n at async /squid/node_modules/.pnpm/@subsquid+typeorm-store@1.5.1_@subsquid+big-decimal@1.0.0_typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2_/node_modules/@subsquid/typeorm-store/lib/database.js:84:13\n at async EntityManager.transaction (/squid/node_modules/.pnpm/typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2/node_modules/typeorm/entity-manager/EntityManager.js:75:28)\n at async TypeormDatabaseWithCache.submit (/squid/node_modules/.pnpm/@subsquid+typeorm-store@1.5.1_@subsquid+big-decimal@1.0.0_typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2_/node_modules/@subsquid/typeorm-store/lib/database.js:164:24)\n at async Runner.withProgressMetrics (/squid/node_modules/.pnpm/@subsquid+util-internal-processor-tools@4.2.1/node_modules/@subsquid/util-internal-processor-tools/lib/runner.js:217:22)","criteria":{"id":"g1K8FRGreTEqB7DH5tWpQWEA75iMWT8dg1UcSoYuU5oWQr1fk"},"message":"Could not find any entity of type \"Account\" matching: {\n \"id\": \"g1K8FRGreTEqB7DH5tWpQWEA75iMWT8dg1UcSoYuU5oWQr1fk\"\n}"}}
En v0.5.11, j’ai toujours cette erreur :
{"level":5,"time":1772703832788,"ns":"sqd:processor","err":{"stack":"EntityNotFoundError: Could not find any entity of type \"Smith\" matching: {\n \"index\": 12483\n}\n at /squid/node_modules/.pnpm/typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2/node_modules/typeorm/entity-manager/EntityManager.js:682:39\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async StoreWithCache.findOneByOrFail (/squid/node_modules/.pnpm/@belopash+typeorm-store@1.5.0_@subsquid+typeorm-config@4.1.1_typeorm@0.3.26_ioredis@5.7_0562d5ed8c2d447272b97a9e909772f4/node_modules/@belopash/typeorm-store/lib/store.js:153:21)\n at async DataHandler.processNewData (/squid/lib/data_handler.js:412:32)\n at async /squid/lib/main.js:91:9\n at async TypeormDatabaseWithCache.performUpdates (/squid/node_modules/.pnpm/@belopash+typeorm-store@1.5.0_@subsquid+typeorm-config@4.1.1_typeorm@0.3.26_ioredis@5.7_0562d5ed8c2d447272b97a9e909772f4/node_modules/@belopash/typeorm-store/lib/database.js:45:13)\n at async /squid/node_modules/.pnpm/@subsquid+typeorm-store@1.5.1_@subsquid+big-decimal@1.0.0_typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2_/node_modules/@subsquid/typeorm-store/lib/database.js:84:13\n at async EntityManager.transaction (/squid/node_modules/.pnpm/typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2/node_modules/typeorm/entity-manager/EntityManager.js:75:28)\n at async TypeormDatabaseWithCache.submit (/squid/node_modules/.pnpm/@subsquid+typeorm-store@1.5.1_@subsquid+big-decimal@1.0.0_typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2_/node_modules/@subsquid/typeorm-store/lib/database.js:164:24)\n at async Runner.withProgressMetrics (/squid/node_modules/.pnpm/@subsquid+util-internal-processor-tools@4.2.1/node_modules/@subsquid/util-internal-processor-tools/lib/runner.js:217:22)","criteria":{"index":12483},"message":"Could not find any entity of type \"Smith\" matching: {\n \"index\": 12483\n}"}}
L’erreur semble survenir lors d’une certification forgeron provenant de l’identité 12483 (vjrj). Il était bien présent au genesis de la gtest, mais il semble qu’il ne soit pas correctement inséré en base, probablement à cause d’une erreur de genesis.
En rentrant dans l’image docker
$ docker run --rm -it --entrypoint sh duniter/squid-app-gtest:0.5.11
$ cat /squid/input/gtest.yaml
Je vois un fichier yaml qui ne contient pas vjrj :
- name: "moul"
- name: "HugoTrentesaux"
- name: "tuxmain"
- name: "1000i100"
- name: "vit"
- name: "cgeek"
- name: "Elois"
# This smith will be the first author
session_keys: "0xbd6d9041890bbf56fa5cb30c3db1b41f7cbf07b04b8a5cf1fb63d79b2029751ecc668b4c0fedf4fd7ac8e44014ffbe16a03b5f55274ac0b94e04e3a0a1fda70ccc668b4c0fedf4fd7ac8e44014ffbe16a03b5f55274ac0b94e04e3a0a1fda70ccc668b4c0fedf4fd7ac8e44014ffbe16a03b5f55274ac0b94e04e3a0a1fda70c"
Donc il y a clairement un problème, jamais ce fichier n’aurait dû arriver là. Je vais inspecter la CI pour voir comment les images sont faites, mais en tout cas ce ne sont pas les bonnes donnée.
J’y ai réfléchi et voici ce que je préconise : ne pas du tout embarquer de données dans l’image de l’indexeur, mais embarquer les données dans une autre image docker montée à l’endroit nécessaire pour que squid les trouve au démarrage. Comme ça les images squid seraient multi réseau et on pourrait reconstuire l’image sans embarquer les donnée du genesis qui ne changeront probablement plus (sauf si on ajoute des données historiques).
Apparemment ce n’est pas la CI qui a buildé la 0.5.11. Et de toute façon je ne vois pas d’où vient la variable RELEASE_TAG qui dit où aller chercher les données parce que les variables sont vides :
Hophophop, je suis sur mobile là, mais attends avant de toucher à ça!
J’ai adapté la CI juste pour le lancement de Dimanche pour la Ğ1, tout roule
pour la gtest le format des release girlab n’était pas le même il fallait entrer à la main un numéro de job CI pour récupérer les artefacts Genesis !
On changera tout comme tu veux mais après le lancement stp, tout est roadé là.
Pour la gtest j’ai dû le faire en local oui avec ton ancien script, avec tout en input, avec le job id que tu avais mis pourtant, il y a du y avoir simplement un couac là, le script existe en .old
Je vais rien changer, je constate juste que les données qui sont dans l’image docker ne sont pas les bonnes, ce qui empêche moul de démarrer son nœud. J’espère juste que samedi les fichiers inclus dans l’image seront les bons. Et il faudrait quand même qu’on fasse une image gtest fonctionnelle si on veut garder ce réseau, et pour que moul puisse tester.
Tu peux vérifier l’image squid Ğ1 elles sont bonnes. Pour gtest il faut le refaire en local mais je sais pas pk ton script n’a pas mis les bons inputs.
Étant donné que le dépôt est configuré pour la Ğ1, laissons-le ainsi, car la priorité c’est la Ğ1.
Je passerais l’indexeur officiel sur la Ğ1 le moment venu. En attendant, il doit être considéré non fonctionnel.
Comment se fait-il qu’on puisse faire ça avec Polkadot-SDK ?
Ça sert à rien. Mais bon, tu n’as pas très intérêt de faire ça étant donné que l’émetteur (si non-identifié) doit surement payer des frais.
Il n’y a aucune raison, d’un point de vue de la blockchain, d’interdire un transfert d’un montant égal à zéro. Toutes les blockchains que je connais l’autorisent (y compris Ethereum), et cela permet de vérifier si un compte arrive à émettre une transaction sans avoir à dépenser d’autres fonds que les frais. Cela permet aussi d’envoyer un message à un autre compte à moindre coût (via une transaction avec commentaire mais à montant nul).
Oui.
Désolé j’ai pas pris le temps de communiquer à ce sujet, ni de trop le tester en profondeur, totalement vibe codé par claude évidamment, stack Nuxt4.
Je tente également de lancer mon indexeur. Je suis parti du dépôt git pour le .env et le docker-compose.yml. J’ai utilisé ces images :
duniter/squid-graphile-gtest:0.5.11
duniter/squid-postgres-gtest:0.5.11
duniter/squid-app-gtest:0.5.11
Au départ la synchro a l’air de partir, puis ça s’arrête brusquement avec ce message d’erreur dans les logs de processor :
{"level":2,"time":1772746353345,"ns":"sqd:processor","msg":"48769 / 2093421, rate: 94 blocks/sec, mapping: 167 blocks/sec, 519 items/sec, eta: 6h 3m"}
{"level":3,"time":1772746353348,"ns":"sqd:processor:mapping","msg":"Validator g1PH3gQ4n53EqpcLVLtG77jRRo71tLUjvDYcm87MENkAa1NPz not found for block 48778, skipping forge count"}
{"level":2,"time":1772746353385,"ns":"sqd:processor:mapping","msg":"48783 SmithMembers.SmithCertAdded"}
{"level":5,"time":1772746353410,"ns":"sqd:processor","err":{"stack":"EntityNotFoundError: Could not find any entity of type \"Smith\" matching: {\n \"index\": 12483\n}\n at /squid/node_modules/.pnpm/typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2/node_modules/typeorm/entity-manager/EntityManager.js:682:39\n at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n at async StoreWithCache.findOneByOrFail (/squid/node_modules/.pnpm/@belopash+typeorm-store@1.5.0_@subsquid+typeorm-config@4.1.1_typeorm@0.3.26_ioredis@5.7_0562d5ed8c2d447272b97a9e909772f4/node_modules/@belopash/typeorm-store/lib/store.js:153:21)\n at async DataHandler.processNewData (/squid/lib/data_handler.js:412:32)\n at async /squid/lib/main.js:91:9\n at async TypeormDatabaseWithCache.performUpdates (/squid/node_modules/.pnpm/@belopash+typeorm-store@1.5.0_@subsquid+typeorm-config@4.1.1_typeorm@0.3.26_ioredis@5.7_0562d5ed8c2d447272b97a9e909772f4/node_modules/@belopash/typeorm-store/lib/database.js:45:13)\n at async /squid/node_modules/.pnpm/@subsquid+typeorm-store@1.5.1_@subsquid+big-decimal@1.0.0_typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2_/node_modules/@subsquid/typeorm-store/lib/database.js:84:13\n at async EntityManager.transaction (/squid/node_modules/.pnpm/typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2/node_modules/typeorm/entity-manager/EntityManager.js:75:28)\n at async TypeormDatabaseWithCache.submit (/squid/node_modules/.pnpm/@subsquid+typeorm-store@1.5.1_@subsquid+big-decimal@1.0.0_typeorm@0.3.26_ioredis@5.7.0_pg@8.16.3_reflect-metadata@0.2.2_/node_modules/@subsquid/typeorm-store/lib/database.js:164:24)\n at async Runner.withProgressMetrics (/squid/node_modules/.pnpm/@subsquid+util-internal-processor-tools@4.2.1/node_modules/@subsquid/util-internal-processor-tools/lib/runner.js:217:22)","criteria":{"index":12483},"message":"Could not find any entity of type \"Smith\" matching: {\n \"index\": 12483\n}"}}
Et ensuite ça ne veut plus redémarrer car ce message revient sans arrêt.
). Désolé pour le faux positif. Ça fonctionne sur mon installation locale.
