Incorrect number of users in the groups overview

support
1

somehow the numbers shown in the groups overview for the trust levels 0-4 are wrong (too high)
We do only currently have 439 user (plus system and discobot). (we had more users in the past)
But the group overview does show:

grafik
grafik1077×352 41.5 KB

when clicked into trust level 0 on the group overview then the correct number is shown:
grafik

trust level 0: 557 but inside 439
trust level 1: 480 but inside 412
trust level 2: 300 but inside 298
trust level 3: 37 but inside 35
trust level 4: 4 but inside 2

a “select count(*) from users” does also show 441 which does match the 439 + system + discobot

The numbers shown for all other groups in the group overview seem to be correct.

How can I correct the numbers in the overview?

We are on the current version 2.6.0.beta5 ( 698b7ace10 ) but that problem was probably also already in older versions.

2

The numbers are corrected regularly, there are some rare cases where they can go out of sync.

https://github.com/discourse/discourse/blob/0cf9a643c1835ac105905aaf2da208e700fca5ad/app/models/group.rb#L470-L474

If you wait up to 12 hours it will fix itself up.

https://github.com/discourse/discourse/blob/0cf9a643c1835ac105905aaf2da208e700fca5ad/app/jobs/scheduled/ensure_db_consistency.rb#L6-L6

Is sidekiq working properly in your install, did you recently delete a large number of users?

1 Like
3

well even after 12 hours they are still incorrect, all values from trust level 0 to trust level 4 were only reduced by 2 (for whatever reason). All other group counters seem to be correct.

grafik
grafik1145×151 3.79 KB

no the last user delete had been already two days ago.
In the last 14 days I did only delete 7 users.
I did delete in the last 1,5 years more than 2000 users. We do have the plugin autosupend in place and are auto supending users that are more than 365 days without activity.These autosuspended users and all their data I do then delete at least once a week, so that we remain EU-GDPR compliant.

Sidekick is working fine, no dead jobs.
As far as I remember the number of jobs that did error out has also not changed in the last couple of days.
What is the queue 0f13eb003564dea87a7cc8f25560ba0e for?
Is that queue needed or should I delete it?

grafik
grafik980×654 80.6 KB

I think I found the problem, the table group_users does still have entries for user_id which do no longer exist and which are no longer in the table users. (in total 182 entries for 117 user_id which do not have a corresponding entry in users)
So somehow the database has some inconsistencies. I do not know how this has happened.
And now the question is, how I can solve it now?
Just manually delete with a sql statement the entries from group_users for which no entry does exist in users?

2 Likes
4

Yeah, no idea how you got to that state though, maybe the result of some migration or something like that?

Deleting is perfectly safe (though as with all things like this, backup your DB prior).

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

If you can find a consistent repro here I would love to fix.

3 Likes
5

thank for your answer, I just did the delete and will check again once the next updates of the overview was done.

1 Like
6

looks fine now, case closed.

1 Like