Nombre incorrect d'utilisateurs dans l'aperçu des groupes

D’une manière ou d’une autre, les chiffres affichés dans la vue d’ensemble des groupes pour les niveaux de confiance 0 à 4 sont incorrects (trop élevés).

Nous n’avons actuellement que 439 utilisateurs (plus system et discobot). (Nous avions plus d’utilisateurs par le passé)

Mais la vue d’ensemble des groupes affiche :

Lorsqu’on clique sur le niveau de confiance 0 dans la vue d’ensemble des groupes, le chiffre correct s’affiche alors :

Niveau de confiance 0 : 557 mais 439 à l’intérieur
Niveau de confiance 1 : 480 mais 412 à l’intérieur
Niveau de confiance 2 : 300 mais 298 à l’intérieur
Niveau de confiance 3 : 37 mais 35 à l’intérieur
Niveau de confiance 4 : 4 mais 2 à l’intérieur

Une requête “select count(*) from users” affiche également 441, ce qui correspond bien à 439 + system + discobot.

Les chiffres affichés pour tous les autres groupes dans la vue d’ensemble semblent corrects.

Comment puis-je corriger les chiffres dans la vue d’ensemble ?

Nous utilisons la version actuelle 2.6.0.beta5 (698b7ace10), mais ce problème existait probablement déjà dans les versions antérieures.

Les chiffres sont corrigés régulièrement ; il existe quelques cas rares où ils peuvent se désynchroniser.

Si vous attendez jusqu’à 12 heures, cela se corrigera tout seul.

Sidekiq fonctionne-t-il correctement dans votre installation ? Avez-vous récemment supprimé un grand nombre d’utilisateurs ?

Eh bien, même après 12 heures, les valeurs sont toujours incorrectes : toutes les valeurs, du niveau de confiance 0 au niveau de confiance 4, n’ont été réduites que de 2 (pour une raison quelconque). Tous les autres compteurs de groupe semblent corrects.

Non, la dernière suppression d’utilisateur remonte déjà à deux jours.
Au cours des 14 derniers jours, je n’ai supprimé que 7 utilisateurs.
Au cours des 1,5 dernières années, j’ai supprimé plus de 2 000 utilisateurs. Nous utilisons le plugin autosupend pour suspendre automatiquement les utilisateurs inactifs depuis plus de 365 jours. Ces utilisateurs automatiquement suspendus, ainsi que toutes leurs données, sont ensuite supprimés au moins une fois par semaine afin de rester conformes au RGPD de l’UE.

Sidekick fonctionne correctement, aucune tâche morte.
Pour autant que je me souvienne, le nombre de tâches ayant échoué n’a pas changé au cours des derniers jours.
À quoi sert la file d’attente 0f13eb003564dea87a7cc8f25560ba0e ?
Cette file d’attente est-elle nécessaire ou devrais-je la supprimer ?

Je pense avoir trouvé le problème : la table group_users contient toujours des entrées pour des user_id qui n’existent plus et qui ne figurent plus dans la table users (au total 182 entrées pour 117 user_id sans correspondance dans users).
Donc, d’une manière ou d’une autre, la base de données présente certaines incohérences. Je ne sais pas comment cela a pu se produire.
Et maintenant, la question est : comment puis-je résoudre ce problème ?
Dois-je simplement supprimer manuellement, via une requête SQL, les entrées de group_users pour lesquelles aucune entrée correspondante n’existe dans users ?

Oui, je ne sais pas vraiment comment vous en êtes arrivé à cet état, peut-être à la suite d’une migration ou de quelque chose de similaire ?

La suppression est tout à fait sûre (mais comme pour tout ce genre d’opérations, faites une sauvegarde de votre base de données au préalable).

./launcher enter app
rails c
DB.exec("delete from group_users where user_id not in (select id from users)")

Si vous pouvez trouver un moyen reproductible et cohérent de reproduire ce problème, je serais ravi de le corriger.

Merci pour votre réponse, je viens de procéder à la suppression et je vérifierai à nouveau une fois que les prochaines mises à jour de l’aperçu seront effectuées.

Ça a l’air bon maintenant, dossier clos.