Club/group membership counting is all messed up...

Consider the current number of members in the Cheating Forum:

https://www.chess.com/clubs/members/cheating-forum

It says that there are 2,337 of them. Now count the number of pages at the bottom: there are 134 pages; 25 members per page on the first 133 pages, 3 members on the last page.

133*25+3 = 3328.

The discrepancy is now about a 1000, and will get bigger after I am done removing closed accounts from that group.

I've already submitted a bug report on this (and have a pretty good idea about what is going on and why), but am wondering if anyone has thoughts about it.

I can't comment on the why, but I think it's a known thing (maybe a V2/V3 mismatch from earlier?). I've synced it just to make sure nothing else was going on — so it shows the correct values now at least.

@chrka: well, here's my theory (a repost from CF notes, but in more readable sequence :-), ending with a suggestion how this should be fixed.

I imagine that the number of members is stored in the database as an attribute of each group, and is updated only when a member is explicitly added or removed. Account closure does not have an effect (presumably because self-closed account can be reopened, and all group memberships re-appear). Involuntary closures also have no effect.

The result is that many groups were showing higher member count than what you got when examining membership list. A group with 8 open accounts and 4 closed accounts would show as having 12 members. So, one day, this was globally adjusted: the membership counters for all groups were reset to the actual number of open accounts.

Now that group with 8 open accounts would show up as having 8 members. Then, a new feature got added: group admins can see members whose accounts were closed, and remove such members from the group. So, the admin of our sample group with 8 members can remove the 4 closed ones. But explicit removals reduce the counter, so the group will be displayed as having 4 members, while still displaying the 8 open accounts as (correctly) being the members.

The same thing happened here. I noticed that the counter was off compared to the list, and started removing closed accounts from the group. I am curious whether we'll reach negative numbers; this is certainly possible for some groups, e.g. a group with 8 open and 12 closed accounts would be showing 20 members in the past, got adjusted to 8, and should show negative four after its admin would remove the closed accounts :-)

The best way of handling this would've been to maintain two counters for each group: the number of active and inactive (closed) members. Change in membership status would update these as necessary: closing an account would decrement the first, and increment the second. Account closures are infrequent enough (compared to everything else), that this would not present any significant workload to the database...

I thought that is what the monthly (or semi-monthly) purges in V2 were doing.. to accurately reflect (active) members only.

Sorry, but as a computer science professor,  I have to say that any project submission for an introductory programming class that suffered from such poor design and testing would be well on the way to a failing grade.