Il faut aller dans “Paramètres > Afficher les dividendes produits”.
Je vais voir ce soir pour modifier un peu cette vue pour mieux comprendre le solde.
Cesium devrait (comme toutes les applications grand public) afficher par défaut un solde qui prend en compte les dividendes non réclamés. Le fait que les dividendes soient désormais réclamés manuellement est une optimisation purement technique qui ne devrait pas impacter les utilisateurs.
Je pensais que nous avions fait cela. Et que le claimUD était fait dès que possible. Tu peux vérifier @zoltounet ? Et tenter de reproduire le bug ? Ça pourrait soulager cgeek.
Oui c’est le cas normalement.
Ne pas confondre l’afficahge des DU produit qui concerne l’historique des DU dans la vie history, et la prise en compte des DU non réclamé dans les soldes, ça n’a rien à voir.
@poka pourrais-tu checker que tout va bien d’après Gecko ?
g1Lxq49GUpKBHuUK99H1jhre6tkzSEDydg9ymLXK3oeAmVMva / g1companion-hypericum
Je n’ai pas réussi à investiguer suffisamment, voici une capture avec un Cesium qui compacte l’affichage des DU :
C’est comme si le solde ne tenait pas compte du dernier DU du 03/03 (à la limite, OK) mais surtout les 43 DU précédents également (507.40GT).
Je le sens pas 
ça sent le bug de claimUd vs migration d’identité.
Bon bah c’est officiel il y a un bug quelque part.
Je continuerai Ă creuser demain.
Je pense que ce compte a été migré sans transfert du solde et que le solde manquant se trouve sur l’ancien compte.
En tout cas, sur la blockchain, ce compte a bien 935,20 GT (923,40 GT + 1 DU non réclamé). Le dernier DU est donc bien pris en compte dans le solde affiché.
@poka Gecko affiche-t-il le même historique passé que Cesium2 jusqu’au bout ?
Si oui, c’est un problème d’historique côté indexeur.
Sinon, c’est spécifique à Cesium2.
Si c’est bien un soucis de Squid dû à la migration d’identité.
En gros Squid affiche le DU en double dans l’historique avant la migration de l’identité:
Tout ce qui est avant cet événement de migration ne devrait pas afficher l’historique des DU, c’est ce qui peut rendre confus.
- udHistory n’est PAS une vraie table - c’est une vue calculée
La fonction SQL identity_ud_history_computed (lignes 69-133 de udHistoryFunction_up.sql) retourne tous les DU créés pendant les périodes de membership de l’identité, sans se soucier de quel compte les a réellement claimés :
FROM universal_dividend ud WHERE EXISTS ( SELECT 1 FROM membership_periods WHERE ud.block_number >= creation_block AND ud.block_number <= removal_block )Cette fonction ne regarde que :
- les blocs de création/suppression de membership de l’identité
- les DU créés (table universal_dividend) pendant ces périodes
Elle ne vérifie jamais si un DU a été effectivement claimé, ni par quel compte.
- Le traitement de UdsClaimed ne crée aucun enregistrement
Dans data_handler.ts:679-703, quand un event UdsClaimed est traité :
// Seule action: mettre Ă jour firstEligibleUd
identity.firstEligibleUd = lastUd.index + 1;Il n’y a aucune insertion dans une table ud_history ou similaire. L’event UdsClaimed (qui contient who = l’adresse du compte qui a claimé) est simplement ignoré pour l’historique.
- Conséquence
La requête identity → udHistory retourne les DU théoriquement dus à l’identité (basés sur les périodes de membership), pas les DU réellement claimés par un compte donné. Après un changeOwnerKey, l’historique des DU pré-migration est attribué au nouveau
compte sans distinction.
Je vais proposer un fix côté Squid qui retourne seulement les DU depuis le bloc de migration, pour voir ce que ça peut donner.
Si l’analyse est la bonne, il ne devrait rien avoir à faire côté apps.
@elois @cgeek voilà c’est corrigé en squid v0.5.10 déployé sur docker hub !
Si vous utilisez le endpoint squid https://gt-squid.axiom-team.fr/v1/graphql, vous verrez qu’il n’y a plus l’historique des DU sur ce compte avant la migration 
Désolé pour le délais excessif pour le diag et le déploiement de ce correctif, claude je vais essayer d’'aller plus vite la prochaine fois.
Et si vous vous demandez pourquoi sont ancien compte g1QbETyAfSn543yDZv7p7XFnesJRoxhMkNjKgH1MxR2ZDbcb3 a encore 1.9 GT, c’est parceque les 600 c’était un transfer keep alive manuel, par un transferAll, donc migration pas faite avec Gecko (g1companion je présume).
J’essaie de relancer un squid en gtest mais j’ai une erreur
{"level":2,"time":1772586983050,"ns":"sqd:processor","msg":"processing blocks from 0"}
{"level":2,"time":1772586983051,"ns":"sqd:processor","msg":"using chain RPC data source"}
{"level":2,"time":1772586983086,"ns":"sqd:processor","msg":"prometheus metrics are served at port 40637"}
🔑 SS58 prefix from chain: 4450
{"level":2,"time":1772586983273,"ns":"sqd:processor:mapping","msg":"Using genesis files from ./input/gtest.json, ./input/genesis.json, ./input/block_hist.json, ./input/tx_hist.json, ./inpu
t/cert_hist.json"}
{"level":2,"time":1772586983273,"ns":"sqd:processor:mapping","msg":"Last v1 block is 0"}
{"level":2,"time":1772586983273,"ns":"sqd:processor:mapping","msg":"Handling v1 block history"}
{"level":5,"time":1772586983276,"ns":"sqd:processor","err":{"stack":"Error: ENOENT: no such file or directory, open '/squid/input/block_hist.json'\n at Object.openSync (node:fs:573:18)\
n at readFileSync (node:fs:452:35)\n at saveGenesis (/squid/lib/genesis/genesis.js:68:55)\n at /squid/lib/main.js:36:49\n at process.processTicksAndRejections (node:internal/process/task_queues:95: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)","errno":-2,"code":"ENOENT","syscall":"open","path":"/squid/input/block_hist.json"}}
$ docker run --rm -it --entrypoint=/bin/sh duniter/squid-app-gtest:0.5.10
/squid # ls -l input/
total 33204
-rw-rw-rw- 1 root root 968 Mar 3 22:25 README.md
drwxrwxrwx 2 root root 4096 Mar 3 22:25 fake
-rw-r--r-- 1 root root 10018918 Mar 3 22:33 g1-data.json
-rw-r--r-- 1 root root 155 Mar 3 22:33 genesis.json
-rw-r--r-- 1 root root 23210175 Mar 3 22:33 gtest.json
-rw-r--r-- 1 root root 1067 Mar 3 22:33 gtest.yaml
-rw-r--r-- 1 root root 738010 Mar 3 22:33 gtest_runtime.compact.compressed.wasm
C’est parceque la CI n’a pas trouvé les artefacts dans la release ?
- tx_hist.json.gz
- cert_hist.json.gz
- block_hist.json.gz
Ah oui c’est ce que je me disais, étrange que la CI n’ai pas échoué, en fait ces artefacts n’étaient pas présent à l’époque de la release runtime gtest 1000, donc c’est pour ça. Il faut que je recréer une version à la mano comme je faisait avant la CI. A partir de la g1 ce sera bon.
Tu plaisantes, tu as déjà été beaucoup plus rapide que nous. On ne peut déjà pas suivre le rythme avec nos tafs à plein temps à côté 
Oui tout est OK pour moi dans Cesium, d’ailleurs j’ai rajouté une feature pour séparer les DU selon le compte qui les produisait afin de pouvoir vérifier que tout est cohérent :
Et sur l’ancien compte :
Ah sympa le merge des DU adjacents, je reprendrais ça dans gecko tiens!
L’opération “Migration d’identité” m’a été soufflée par Ğecko, c’est de bonne guerre 