Putting this on the radars of @Cparle and @AnneT and @MarkTraceur 👀

Reassess the need for withholding remaining unreviewed labels in onPageContentSaveComplete, and consider removing that behavior

To give a little more background here, my original intent was to check that an image originally eligible for CAT inclusion based on the number of existing depicts statements did not fall out of eligibility as a result of the addition of new depicts statements outside CAT, and to withhold it from being served if it did so become ineligible.

That being said, the uploader would be seeing the same behavior here even if the sole unreviewed label had been left in unreviewed (0) state. Actually, the situation would be slightly worse in that case, because a different user could also possibly encounter the image in the "Popular" tab.

I think the important thing is to improve our treatment of deleted items and how this situation is handled in the frontend. As for this suggestion, I'll be bold and delete it.

Discussed this in sd-eng today. In the long run, the querying logic should be updated so that it doesn't rely on the labels being in a "consistent" state.

I've updated the description to take out some of my earlier analysis of "consistent label state" because it's potentially misleading. There shouldn't be a requirement that all suggested labels for an image be collectively voted-upon or not as a group, and there wasn't intended to be such a requirement. The real issue was that we needed to improve handling of suggestions without displayable label text (possibly because the item had been deleted) (T250742).

So afaict the fix for T250742 should prevent this from happening from now on. Do we need a script to clean up labels for already-blocked images?

I don't think so — now that the fix is in, any currently blocked images should get unblocked as soon as votes are submitted again.

I'm not sure that this needs any further attention. By coincidence I also had an image with Q6484949 and no other suggestions in my personal uploads queue, but I was able to remove it by adding my own tag.

@Ramsey-WMF do you think that's sufficient?

Closing because if this rare instance does occur, the Add Tag functionality allows the user to get out of this state.