Flag count suddenly wrong (gap between flag_content & flag_counts)

I would have more expected the flag_counts table to be the one with the higher count, as I seem to remember there's an issue about how that doesn't get handled when users are deleted.

Could you try to reproduce this on a dev copy and report your finding & the steps to take please?

This issue looks like a copy of #1931170: The {flag_counts} table got out of sync, which does have some code to get the tables in sync again – anyway, I don't know how to reproduce the bug, either. Repeating here: I have proof-read all the code grepping for all the occurences where {flag_counts} table gets touched, and found nothing that can yield this result.

I have found the root of the problem. It was suspicious that the {flag_counts} table had the same count value for two different fid values (but the same content_type and content_id values). So the bug does not exist if there's only one flag type. What's triggering it? Having a close look on what happens on the site when the bug is triggered (and having a great bunch of related d.o issues in my mind) revealed that the problem arises when deleting a user who does have flagged anything, and there's more than one type of flags. So I had another close look on the code, and found the culprit: hook_user_cancel() (and hook_user_delete(), too) calls flag_user_account_removal(), which starts by a left-joined SELECT on the related tables, but the ON clause contains only two of the three indexes: content_id and content_type. In other words, fid is missing from the SELECT of flag_user_account_removal(), which means both (all) the flag types will have the same count values when the function returns. This means the counters will definitely be screwed up: two (all) of the counters will have the same value, which belongs to only one of them.

Stepping a bit back shows that the content_type index is not needed at all in the ON clause, since a flag type may belong to only one content_type, which can be clearly seen from the other parts of code of the affected function.

Attached is a patch against today's 7.x-2.x git, which applies to 7.x-2.0 (the latest stable release) with some offset, and has been tested locally with satisfying results.

Nice job tracking down the bug! :)

Indeed, if you have multiple flags on the same entity type then this join could produce multiple rows, as there will be multiple rows in flag_counts for a given entity type and id!

> $query->leftJoin('flag_counts', 'c', 'fc.entity_id = c.entity_id AND fc.entity_type = c.entity_type');

This does however need fixing on 3.x first, where the table names are different. If you could reroll this on 3.x that would be super :)

Resetting issue statuses.

Great work!

Thanks Boobaa,

Same issue with two flags on the same node. the request called when a user is deleted iterate on the two count of the two flag but with the same fid. And then one of the flag is decrease twice (but on each with a starting value which correspond to the count value of the two flag).

Attached the patch port on 7.x-3.x

I've tested it against 3.3. There seems to be something wrong in HEAD that's causing the automated tests to fail. Not sure if that's just my system.

#9 works for me
running 7.x-3.2+7-dev

Longer term idea for the flag count system: #2157157: Change {flag_counts} table to be a cache. I'd appreciate the opinions of users of the flag count functionality!

Committed to 3.x. Thanks everyone!

git commit -m "Issue #1930320 by flocondetoile, Boobaa: Fixed error in flag counts caused when a user is deleted and multiple flags are present on the same entities." --author="boobaa "