Ce bug n’est pas évident à résoudre :
- si on supprime l’ancienne identité il faut aussi supprimer les certifications qui pointent vers elle, ce qui limite l’intérêt de l’indexeur
- si on veut créer une nouvelle identité pour le même compte, ça impose de retirer la contrainte
@uniquequi est très pratique (un compte ne peut être associé qu’à zéro ou une identité) - si on rend nullable le champ account de identity, ça complique un peu la logique côté client puisqu’il n’est plus garanti qu’une identité soit associée à un compte
Si quelqu’un a une solution astucieuse, je suis preneur 
Pour choisir le moindre mal, voici les conséquences des trois propositions ci-dessus :
- Dans ce cas, on perd la trace des certifications émises vers des identités qui n’ont pas abouti, ce qui rend difficile l’explication de certains phénomènes. Exemple : je certifie qqun qui est sur le point de perdre son dossier d’adhésion, ce qui supprime ma certification, et je ne comprends alors pas pourquoi je ne peux plus certifier dans les cinq jours, puisque la trace a disparu.
- Dans ce cas, les développeurs de clients doivent gérer le cas rare où un compte est associé à plusieurs identités, dont au plus une n’a pas le statut “removed”. Ça veut dire que dans une requête graphql, account.identity est une liste (0, 1 ou plus éléments) et plus un élément nullable (0 ou 1 élément).
- Dans ce cas, les développeurs de clients doivent gérer le cas où une identité n’est pas associée à un compte. Ceci n’est censé arriver que pour les identité “removed”, mais il devient alors plus compliqué d’afficher quelle est la clé publique associée à cette identité.
Vu les conséquences, je vais adopter la solution 3.