Comment vous testez vos apps?

Support Duniter-v2
1

Salut,

Pour tester g1-papi, je démarre duniter en sealing mode et je lance toute une batterie de tests en faisant avancer la blockchain avec :

const response = await fetch('http://localhost:9944', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ jsonrpc: '2.0', id: 1, method: 'engine_createBlock', params: [true, false] }),
  })

  return await response.json()

Ça marche plutôt bien et ça permet surtout de faire des transactions en moins d’une seconde au lieu de plus de 20s en mode normal…

Pour g1companion, jusqu’à maintenant, je me démerdais pour “mocker” les appels graphQL vers l’indexer pour les tests. Mais ça devient vite un cauchemar avec des scénarios un peu complexe comme la création et migration d’identité, certifier et changement de certifications, tout le process pour devenir membre…

J’ai cherché dans les codes de gecko et cesium2, et je ne vois pas de tests pour des scénarios de ce type ? ping @poka @kimamila
Comment vous testez ces scénarios ?

Du coup, j’essaye de lancer squid branché sur duniter en sealing mode, mais sans succès.
Quelqu’un a déjà fait ça ?

2

Même sans être en sealing mode, je n’arrive pas à démarrer l’indexer.
J’ai toujours cette erreur :

{"level":5,"time":1758626190353,"ns":"sqd:processor","err":{"stack":"RpcError: Client error: Api called for an unknown Block: State already discarded for 0x6e435634977c8e1b81e4c0bf420aff305baddf3ae207d23a5af63456d797f2e6\n    at captureMissingBlock (/squid/node_modules/.pnpm/@subsquid+substrate-data-raw@1.2.0_@subsquid+logger@1.4.0_@subsquid+rpc-client@4.11.0_@_55b9e8ff4411263b750e6852eedcfceb/node_modules/@subsquid/substrate-data-raw/lib/rpc.js:69:15)\n    at RpcClient.receiveResult (/squid/node_modules/.pnpm/@subsquid+rpc-client@4.11.0/node_modules/@subsquid/rpc-client/lib/client.js:366:28)\n    at /squid/node_modules/.pnpm/@subsquid+rpc-client@4.11.0/node_modules/@subsquid/rpc-client/lib/client.js:275:29\n    at processTicksAndRejections (node:internal/process/task_queues:95:5)\n    at runNextTicks (node:internal/process/task_queues:64:3)\n    at process.processImmediate (node:internal/timers:449:9)","code":4003,"rpcUrl":"ws://host.docker.internal:9944/","rpcId":81,"rpcMethod":"state_getRuntimeVersion","rpcParams":["0x6e435634977c8e1b81e4c0bf420aff305baddf3ae207d23a5af63456d797f2e6"],"rpcResponse":{"jsonrpc":"2.0","id":81,"error":{"code":4003,"message":"Client error: Api called for an unknown Block: State already discarded for 0x6e435634977c8e1b81e4c0bf420aff305baddf3ae207d23a5af63456d797f2e6"}}}}
Gracefully stopping... (press Ctrl+C again to force)
dependency failed to start: container squid-processor-1 is unhealthy
3

C’est probablement que tes volumes Docker sont mal prunés.
Ca m’arrive parfois, uniquement avec Squid, même si je down -v, je rm le volume manuellement, et même volume prune ne suffit pas, seul un docker system prune -a fonctionne chez moi si tu as le même problème que moi.
Ca va te supprimer toutes tes images, volumes et container locaux qui ne sont pas démarrés (coupe bien les container squid avant donc).
Test pour voir si c’est ça. Si oui il faudrait trouver plus précis pour bien prune les volumes squid, mais au moins ça peut débloquer la situation, dis moi.

Sinon vérifie bien que ton container Squid utilise le même réseau interne Docker pour qu’ils puissent communiquer au vue de ta config.
Mais je pense que c’est le cas, au vue de l’erreur, mais à vérifier quand même.

4

Cool ! Merci @poka

Ok, ça passe mon bug. Maintenant ça veux indexer le genesis.
J’essay de passer les bugs un par un en fouillant le code de duniter-squid et en générant un genesis.json de base.
Mais galère pour les identités, faut transformer les noms en Array du style :

"name": [
                65,
                108,
                102,
                121,
                98,
                101
              ],

Vous n’avez pas du code qui transforme un fichier default.json que l’on passe à duniter en DUNITER_GENESIS_CONFIG en fichier genesis.json pour squid ?
Ou un moyen de générer ce genesis.json depuis une instance duniter qui tourne ?
Mais vous faites comment depuis le début pour tester ???

Je sens que ça va péter avec le runtimeGenesis.code…

5

Non je crois que tu confonds, il ne faut pas transormer les noms en array. Ce que tu sembles montrer ce sont les idtyIndex des certificateurs de l’identité name. , du bloc json identity du genesis.
Il n’y a pas de conversion particulière pour squid. On peut se call si tu veux.

6

Non, c’est bien le nom. J’arrive à les construire avec :

str = "Alice";
uint16Array = new Uint16Array(
  Array.from(str).map(char => char.charCodeAt(0))
);

console.log(uint16Array);

Bon, j’arrive à démarrer squid ! Mais c’est bancal…
Je me demande bien comment vous faites vos tests pour tout ce qui est création/confirmation/validation d’identité…

C’est sur la branch squid : Files · squid · libs / g1-papi · GitLab

Ce que je veux, c’est pouvoir redémarrer duniter et squid pour lancer des tests. Mais j’ai des erreurs à chaque nouveau DU. Puis relancer squid ça prend plus de 10 secondes à cause d’hasura. Et je ne trouve pas de moyen de dump la bdd et relancer squid sans down tous les dockers.
De toute façon, j’ai fait tout ça pour rien. Sans oracle ça ne peux pas marcher…

Je retourne faire des “mocks” d’appel graphql pour g1companion. Mais c’est un enfer à gérer. J’ai essayé il y a 15 jours de démarrer squid. Puis j’en suis venu à tout mocker.
C’est quand même galère de ne pas avoir d’environnement de tests totalement fonctionnel…

1 Like
7

Perso je ne test pas squid, uniquement un noeud duniter local et le squid du réseau de dev.
Quand c’est vraiment nécessaire, je mock.

Mais oui il faut améliorer l’env de dev squid. La refonte avec PostGraphile va dans ce sens :slight_smile:
Il n’y a plus toutes les metadata à gérer.

D’ailleurs tu ferais bien d’utiliser ma branche postgraphile directement comme je te le disais, car on va bientôt merger, tôt ou tard il faudra passer dessus.

2 Likes
8

J’ai fait pareil jusqu’à maintenant, mais pour des test de scénarios de certification, c’est un calvaire car l’état diffère entre ton noeud duniter local et les réponses graphql.
Et puis tu as 3 comptes certifiés en permanence sur la gdev ? Et pour faire des tests avec un user en mode unconfirmed/unvalidated… ?
D’ailleurs je ne trouve même plus de comptes certifiés sur la gdev !

Je veux bien, mais c’est déjà compliqué avec l’état actuel des squids qui sont à moitié gdev et gtest. Là on va se retrouver en plus avec des indexeurs avec une api graphql à la postgraphile…
Il y a des postgraphiles qui tournent pour la gdev et la gtest ?
Comment tu fais pour vérifier que ton endpoint est hasura ou postgraphile ?

9

Regarde le dépôt de Tikka. J’ai réussi à faire un docker compose gdev Squid avec les users Alice Bob etc, dans l’état initial que je veux. Par contre je n’y arrive pas pour la gtest. Du coup pour des tests end 2 end sur la gtest, je fais sans Squid pour l’instant.

Mais quand les tickets des images docker seront réglés ont devrait pouvoir lancer gtest duniter + Squid en local avec des utilisateurs prédéterminés à chaque relance des tests.

J’ai un bash dans bin qui lance docker compose, puis lance les tests, puis détruit les containers.

1 Like
10

Ah génial !

Comment tu as généré le fichier gdev.json ? À la main ?

11

C’est dans le document markdown CONTRIBUTING.md :

Create your own squid gdev.json file

Build chain specs of local network:

gdev:

docker run -ti --rm --entrypoint "" duniter/duniter-v2s-gdev-800 duniter build-spec --chain=dev > input/gdev.json

gtest:

docker run -ti --rm --entrypoint "" duniter/duniter-v2s-gtest-1000 duniter build-spec --chain=dev > input/gtest.json

Pour lancer un compose :

docker-compose --env-file docker/.env --file docker/docker-compose-gtest.yaml -p docker/ up

2 Likes