Tu as un bouton pour ouvrir l’extension dans une nouvelle popup.
Ah oui c’est vrai, j’avais oublié !
Du coup bloc 584595, balances.ReserveRepatriated indique la transaction avec tout ce qu’il faut.
Du coup je ne comprends pas bien si je dois me fier uniquement aux events Unreserved + SwapClaimed, ou ReserveRepatriated.
Si je les appliques tous ça risque de faire doublons non?
Les événements swap semblent plus pertinents pour labelliser les transactions (ils ne contiennent aucune info monétaire), comme les commentaires, tandis que les transactions sont marquées par les mouvements de réserve.
Donc pour suivre le montant du compte, les Reserved, Unreserved et ReserveRepatriated devraient suffire ?
1 Like
Juste Reserved et Unreserved en fait.
→ Problème, ces deux events étaient déjà pris en compte dans squid…
// Process reserved amounts
for (const reserved of newData.reserved) {
// ctx.log.debug(`New reserve: ${reserved.address} reserved ${reserved.amount} tokens`);
await this.updateAccountBalance(ctx, reserved.address, -reserved.amount);
}
// Process unreserved amounts
for (const unreserved of newData.unreserved) {
// ctx.log.debug(`New unreserve: ${unreserved.address} unreserved ${unreserved.amount} tokens`);
await this.updateAccountBalance(ctx, unreserved.address, unreserved.amount);
}
Je rajoute donc ReserveRepatriated pour voir, uniquement le kind Free qui ne génère peut être pas d’event Reseverd
Pour info j’ai fait un script pour m’aider à debug en comparant le compute des balances par 3 moyens différents:
- Via RPC (
UniversalDividendApi_account_balances) - Via le field
totalBalancede l’indexer - En sommant l’historique des tx et ajoutant les DU à la volée via l’indexer
J’obtient des résultats strictement identiques pour tous ceux que j’ai testé, sauf pour Tuxmain:
./test_balances_sources.py -a g1L1ebhZUTNzbnHgKDGKwTCkFBgqc55WP6EC53saBTA6sGgaU
┌─────────────────────────────────────┐
│ Balance mismatch │
│ my_balance : 4699732 │
│ graphql_total : 4699582 (Δ 150) │
│ duniter_total : 4699682 (Δ 50) │
└─────────────────────────────────────┘
3 valeurs différentes en fonction de la source. 0.5GT de différence entre mon compute manuel et RPC. Là je sèche.
Sachant que mon compute manuel fait dans gecko et duniter portal donne le même résultat que celui du field totalBalance de l’indexer (donc différent de RPC).
En fait je vois aussi un différence avec Maaltir:
./test_balances_sources.py -a g1MLRHmSjaBV12xJVSERXmrtWhbR3Liz925iLMBjv7jCkyA8t
┌─────────────────────────────────────┐
│ Balance mismatch │
│ my_balance : 688394 │
│ graphql_total : 688394 (Δ 0) │
│ duniter_total : 685394 (Δ 3000) │
└─────────────────────────────────────┘
5 Likes
La commande UniversalDividendApi_account_balances inclus le montant réservé et le dépôt d’existence.
J’ai implémenté la balance totale dans Tikka (pour la prochaine release), selon deux méthodes pour être compatible avec la gdev qui n’a pas la commande ci dessus.
J’ai galéré car sans cette commande il manque les 100 du dépôt d’existence qu’il faut aller récupérer dans les constantes.
Pour égaler le total RPC, il faut le
System. Account free + reserved + constant existential deposit + unclaimed UDs.
Mais je ne sais pas si cela peut expliquer les anomalies constatées…
Bah je ne pense pas car comme je l’ai dit, c’est bon pour certain mais pas pour d’autre.
Moi je n’ai aucune June reserved.
system.account: FrameSystemAccountInfo
{
nonce: 21
consumers: 1
providers: 1
sufficients: 1
data: {
free: 4,005,821
reserved: 0
feeFrozen: 0
linkedIdty: 58
}
}
Maaltir : n’a aucune June reserved, comme moi.
system.account: FrameSystemAccountInfo
{
nonce: 20
consumers: 0
providers: 2
sufficients: 1
data: {
free: 680,394
reserved: 0
feeFrozen: 0
linkedIdty: 2,703
}
}
Tuxmain : a 100 centimes en reserved, qui manquent dans le calcul GraphQL.
system.account: FrameSystemAccountInfo
{
nonce: 15
consumers: 2
providers: 1
sufficients: 1
data: {
free: 4,658,582
reserved: 100
feeFrozen: 0
linkedIdty: 1,401
}
}
Ma supposition ici est que :
- A. le second calcul oublie les Junes réservées, mais inclus bien le dépôt d’existence.
- B. Tuxmain a peut être fait des tests de transferts avec conditions complexes après genesis qui sont gérés différemment entre les différents calculs. (atomic swap, autres?).
- C. On est sûr que l’indexer part avec les mêmes soldes du genesis V1 que Duniter ?
- D. La réponse D.
2 Likes
La réponse B !
J’ai un pending atomic swap, vous pouvez le trouver dans le storage :
atomicSwap.pendingSwaps(g1P6PGjqZpNjwnnpddjwzcyWiCZAoqeqxZusfUUDRMLPB5X8f)
Ce qui m’étonne c’est que son bloc d’expiration (513 716) est passé depuis longtemps (là on en est au 685 237). Il faudrait chercher s’il y a un bug dans cette palette.
2 Likes
Donc comment expliquer les 30GT de différence ?
Ok donc ça explique les 0.5GT de différence. Donc ça veut dire qu’il manque un event pour ça côté indexer. Et la GT reserved semble expliquer le reste, mais c’est pas le cas pour Maaltir du coup.
edit: Non mais Maaltir match bien entre RPC et le solde Gecko, donc il doit y avoir un bug compute UDs dans l’indexer ET mon compute manuel du script, je ne vois que ça…
C’est un peu le bordel mais je pense qu’avec toutes ces sources ont a tous les éléments pour déméler.
edit: Non le soucis pour Maaltir ne semble pas venir des DU non réclamés…
1 Like
I’m not sure if you guys are aware, but I’m getting negative results (this the old migrated account of @maaltir):
query AccountBalance($id: String! = "g1PiwKceeoNawuUgTuspxLH1vCeRd8UbXkMnPn3aQyDZRYU22" ) {
accounts(filter: { id: { equalTo: $id } }) {
nodes {
id
balance
totalBalance
}
}
}
gives:
{
"data": {
"accounts": {
"nodes": [
{
"id": "g1PiwKceeoNawuUgTuspxLH1vCeRd8UbXkMnPn3aQyDZRYU22",
"balance": "-10085",
"totalBalance": "-10085"
}
]
}
}
}
via rpc to an endpoint gives 0.
1 Like