Refactoring des événements et des erreurs

Nodes Duniter-v2s
1

Bonjour à tous,

Je suis en train de refactorer les événements et les erreurs de nos palettes Substrate. Pour rappel, “une palette peut émettre des événements lorsqu’elle souhaite envoyer des notifications sur des changements ou des conditions en cours d’exécution à des entités externes telles que des utilisateurs, des explorateurs de chaînes ou des applications décentralisées (dApps)”.

La liste des événements est alors placée dans le bloc et ne coûte qu’une lecture et deux écritures par bloc, donc leur coût est relativement faible, et le choix d’en ajouter/retirer est dicté par leur utilité pour le front-end.

Actuellement, toutes nos palettes implémentent des événements positifs (IdtyCreated {idty_index: T::IdtyIndex, owner_key: T::AccountId}) et des erreurs en cas d’échec (IdtyAlreadyCreated). Il est à noter que les erreurs ne peuvent pas contenir d’arguments. Seule la palette quota implémente des événements négatifs (NoQuotaForIdty(IdtyId).

Une stratégie de refactoring pourrait être la suivante :

  1. Conserver les événements positifs.
  2. Ajouter des événements négatifs en cas d’erreurs nominatives (IdtyAlreadyCreated, NoQuotaForIdty) qui permettraient d’informer directement l’utilisateur de la raison de l’échec.
  3. Conserver les erreurs qui sont obligatoires lorsqu’un extrinsic échoue,
    et ne pas les accompagner d’un événement négatif lorsque l’erreur
    dépend de l’état de la chaîne et non d’un problème inhérent à
    l’utilisateur (RefundQueueFull).

La question est de savoir (et plus particulièrement pour ceux travaillant en front-end) si un refactoring en profondeur leur est utile, ou si l’état actuel (avec une harmonisation entre palettes et une bonne documentation) est suffisant et s’il y a d’autres besoins.

3 Likes
2

Les exemples que tu donnes correspondent à des no-op. Est-ce qu’une no-op est une erreur ou un succès ? Est-ce qu’on doit avoir un événement pour une no-op ?

Pour contextualiser, ce n’est pas un refactoring très coûteux en travail, et ça ne va pas casser grand chose en l’état actuel vu le faible nombre de logiciels utilisateurs. Je pense que ça vaut le coup de penser ce système dans l’ensemble pour que l’API des événements soit plus facilement compréhensible.

3

La question est là, il faut forcément une erreur pour une no-op, car c’est le type de retour attendu par Substrate. Il revient à la palette de lui adjoindre, ou pas, un événement, qu’il soit un succès ou un échec.

Si l’on se réfère à Substrate, ils adoptent clairement une approche consistant à générer des événements en cas de succès (donc entraînant un changement d’état de la chaîne) et des erreurs en cas d’échec, par exemple, NoQuotaForIdty serait implémenté comme une erreur générique selon cette approche.

1 Like
4

Ok, donc il faut aussi que link_account retourne une erreur en cas de no-op. Je m’étais posé la question en implémentant mais là tu fermes cette zone d’ombre :slight_smile: