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é)
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.
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 ?
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.