TL;DR : je suis fatigué et pressé d’avoir affaire à la Ğ1
En me promenant par hasard dans les identités sur Duniter Panel, j’ai trouvé Zheny
(index 209, addresse 5GWRRzsgvtZuDp5xREFGwtXnPoH6CYoM1yNwyLabDd1eeicn
) qui est membre mais n’a que 4 certifications. Ce n’est pas un artefact de l’indexeur, puisque Duniter est d’accord sur ça :
> identity.identities(209)
{
data: {
firstEligibleUd: 1
}
nextCreatableIdentityOn: 0
oldOwnerKey: null
ownerKey: 5GWRRzsgvtZuDp5xREFGwtXnPoH6CYoM1yNwyLabDd1eeicn
nextScheduled: 5,184,263
status: Member
}
> certifications.certsByReceiver(209)
[
[
45
9,927,559
]
[
49
10,370,140
]
[
781
10,446,959
]
[
1,386
4,885,368
]
]
> certifications.storageIdtyCertMeta(209)
{
issuedCount: 3
nextIssuableOn: 2,296,772
receivedCount: 4
}
> membership.memberships(209)
{
expireOn: 5,184,263
}
[investigation en cours]
1. Trouver le moment où la certification a expiré
query MyQuery {
certEvent(where: {cert: {receiver: {name: {_eq: "Zheny"}}}}, orderBy: {blockNumber: DESC}) {
blockNumber
eventType
}
}
→ ça a eu lieu au bloc 1,262,656 = 0xf7476ad2a965beb24fd9ba70d76c14a39d6aca0fd05904d62249b92d37dfd6c2
C’est à ce moment que Zheny passe de 5 certifications reçus à seulement 4 tout en restant membre.
2. Lire le code qui gère ça
do_remove_cert()
appelleT::OnRemovedCert::on_removed_cert();
avec l’inforeceiver_received_count
- le handler devrait appeler
do_remove_membership()
avec la raisonMembershipRemovalReason::NotEnoughCerts
- il y a bien un test unitaire qui gère ça dans
pallets/duniter-wot/src/tests.rs
:test_certification_expire()
, le fonctionnement attendu est bien testé, mais pas observé sur la gdev
3. Se rendre compte qu’il suffit de 3 certifications sur la gdev
> wot.minCertForMembership()
3
→ retirer le tag bug
→ changer le titre
→ délister le sujet
→ retourner au lit