Je pense qu’il y a un gros bug dans le storage gdev.
Mon sujet révélateur ici est le compte de @Maaltir 5FPRZxVJGSzi8f8o5ue6uBbnQidMGm2XTLrESiQhWFJRLwdC :
{
nonce: 34
consumers: 0
providers: 2
sufficients: 1
data: {
free: 3,698,398,250,752
reserved: 0
feeFrozen: 0
linkedIdty: 2,703
}
}
{
data: {
firstEligibleUd: 1,628 <-- really??
}
nextCreatableIdentityOn: 4,043,576
oldOwnerKey: [
5GosZYTL75W3J4K8JvtRjeNBrYAz3tgEqxV1Si5XPurJScvz
1,250,887
]
ownerKey: 5FPRZxVJGSzi8f8o5ue6uBbnQidMGm2XTLrESiQhWFJRLwdC
nextScheduled: 4,685,738
status: NotMember
}
Celui-ci n’est plus membre depuis le 8 Décembre. Un claimUd a donc été fait automatiquement à cette occasion.
{
"id": "5FPRZxVJGSzi8f8o5ue6uBbnQidMGm2XTLrESiQhWFJRLwdC",
"balance": 3698398250752,
"totalBalance": 3698398250752,
"identity": {
"name": "Maaltir",
"isMember": false,
"firstEligibleUd": 0,
"udHistory": [
{
"timestamp": "2024-12-08T21:20:54.001+00:00"
}
]
},
"linkedIdentity": {
"accountId": "5FPRZxVJGSzi8f8o5ue6uBbnQidMGm2XTLrESiQhWFJRLwdC"
}
}
Problème: Son solde réel balance.free contient bien l’ensemble de ses DU car le claimUd a été effectué au moment de sa perte d’adhésion, mais son firstEligibleUd vaut toujours 1628, alors qu’il devrait valoir 0, non ?
Je n’ai pas encore été vérifier dans le code de Duniter, je voulais d’abords savoir si il s’agit d’un gros bug, ou bien d’une mauvaise interprétation de ma part ?
Résultat pour Ğecko ou Duniter Portal, son solde est beaucoup trop élevé car les DU éligibles sont doublés:
On peut patcher ça côté client en rajoutant un check si le compte a une identité au statut membre avant de calculer les DU non réclamés, mais ça ne me semble pas normal, pour moi le comportement attendu est de passer le firstEligibleUd à 0 lorsque l’identité n’est plus membre.
PS: stp @Maaltir ne touche à rien sur ton compte avant qu’on ait éclaircie ce soucis, ça m’évite de devoir chercher un autre sujet.
Je viens de patch gecko avec un check isMember:
un “vilain quack” repéré et corrigé 