Réparer les incohérences du storage

Networks ĞDev
1

Dans le post Sanity tests - #6 by HugoTrentesaux, je révèle un problème identifié par @guenoel lors de son travail sur le panneau de monitoring forgeron.

L’identité 2457 est un doublon de l’identité 2453 (Hugo) et l’identité 3595 est un doublon de l’identité 3594 (Manu).

Depuis l’histoire ĞDev -- j'ai perdu mon identité j’ai une nouvelle identité 7238. Celle de manu est toujours 3595.

Voici ce que je propose :

  • supprimer l’entrée identity.identities(2457) dont la clé est
    0x2aeddc77fe58c98d50bd37f1b90840f918373f80b4a94950c1f99840fd083e6884be9c0b10efc23d99090000
  • supprimer l’entrée membership.membership(2457) dont la clé est
    0x2ce461329fdf4be12bce01afc0af09bc2ce461329fdf4be12bce01afc0af09bc84be9c0b10efc23d99090000
  • supprimer l’entrée identity.identities(3594) dont la clé est
    0x2aeddc77fe58c98d50bd37f1b90840f918373f80b4a94950c1f99840fd083e68eb343f1f1a7549380a0e0000
  • supprimer l’entrée membership.membership(3594) dont la clé est
    0x2ce461329fdf4be12bce01afc0af09bc2ce461329fdf4be12bce01afc0af09bceb343f1f1a7549380a0e0000

Est-ce que vous voyez d’autres choses à corriger ? Est-ce que quelqu’un voudrait soumettre une proposition avec un batch call qui corrige ces incohérences ?

2

Ça pose aussi la question de :

  • cert.certsByReceiver(2457)
  • cert.certsByReceiver(3594)
  • cert.storageIdtyCertMeta(2457)
  • cert.storageIdtyCertMeta(3594)
  • smithCert.storageIdtyCertMeta(2457)
  • smithCert.storageIdtyCertMeta(3594)
3

Autre incohérences à réparer : les clés du storage ont été modifiées. Ainsi

smithsMembership.counterForMembership était 0xd9c3e86a769fcdab26d11127983b834f65cd6a25c6273788a61a301e88039d20
smithMembership.counterForMembership est 0xc4d3a9ae16a35ffc8be0f4aca62111e765cd6a25c6273788a61a301e88039d20

Reste à trouver les autres, copier la valeur à l’ancienne clé dans la nouvelle, supprimer l’ancienne, et voir les bugs que ça peut amener…

4

Voilà le tableau des clés à corriger :

clé smiths smith
smithCert.certsByReceiver 0xfaa7133390b9d064aab9e19f3c173af205246731105984b749eb540961191a53b4def25cfda6ef3a00000000 0xe3aef4c495abedaddb881352914a4e2005246731105984b749eb540961191a535153cb1f00942ff401000000
smithCert.palletVersion 0xfaa7133390b9d064aab9e19f3c173af24e7b9012096b41c4eb3aaf947f6ea4290000 0xe3aef4c495abedaddb881352914a4e204e7b9012096b41c4eb3aaf947f6ea42900000
… … …
smithMembership.counterForMembership 0xd9c3e86a769fcdab26d11127983b834f65cd6a25c6273788a61a301e88039d20 0xc4d3a9ae16a35ffc8be0f4aca62111e765cd6a25c6273788a61a301e88039d20
smithMembership.palletVersion 0xd9c3e86a769fcdab26d11127983b834f4e7b9012096b41c4eb3aaf947f6ea429 0xc4d3a9ae16a35ffc8be0f4aca62111e74e7b9012096b41c4eb3aaf947f6ea429
… … …

Qui veut écrire un script une migration pour bouger toutes les clés du storage avant que la ĞDev ne s’effondre pour cause d’absence de forgeron parce que nous ne pouvons pas renouveler nos adhésions forgeron ?

6

Ce serait plus simple de faire un RAZ de la ĞDev.

La migration va se retrouver dans la palette alors que pourtant celle-ci n’a pas changé, ça ne me semble pas approprié. De manière plus générale, renommer une palette, ça ne nous arrivera probablement jamais.

Sans parler des valeurs que tu indiques dans le tableau, je suis incapable de les contrôler (savez-vous le faire ?) et quand bien même ce serait le cas, il suffit d’un évènement dans la blockchain entre-temps pour que les valeurs de migration ne soient plus bonnes (le temps que l’upgrade du runtime survienne).

7

Peut-être qu’on peut le faire avec l’extrinsic system.setStorage, par exemple :

system.setStorage(
  [
    0xc4d3a9ae16a35ffc8be0f4aca62111e765cd6a25c6273788a61a301e88039d20
    0x08000000
  ]
)

Puis system.killStorage pour supprimer les anciennes clés.