I recently got this question in the Close Votes queue (screenshot for <10k users). Before I voted to close it, it had 2 votes to close it as a duplicate, 1 vote to close it as "off-topic" and 1 vote to close it as "unclear what you're asking". I voted to close it as "unclear what you're asking".

So at the end, there were two votes to close as a duplicate and two votes to close as "unclear what you're asking". According to this answer, the last close vote will be used to determine the close reason in case of a tie. In this case, the last close vote was mine and the reason was "unclear what you're asking". But it was still closed as a duplicate.

What's going on here? Is this a bug? Is the answer I linked to wrong? Is there a special case for duplicates? Something else?

• This newer post agrees with the post you linked. Commented Dec 17, 2017 at 12:25
• Dupes aren't really "closes" though, so they may win out. Commented Dec 17, 2017 at 18:45
• @Shog what exactly was fixed? Can you elaborate? Commented Jun 6, 2018 at 13:48
• @Shog well, I did wait few minutes before asking... you could edit your answer before adding the tag... ;) Commented Jun 6, 2018 at 14:04
• I honestly didn't expect anyone to care, @Shadow; this is an extremely obscure bug, which I only fixed because the fix was exceedingly trivial. But since you asked... Commented Jun 6, 2018 at 14:09
• – gnat
Commented Nov 29, 2019 at 19:23

Looks like there's a slight bug here...

Normally, the way consensus is determined when closing is by...

2. Grouping those sorted votes by close reason
3. Sorting the groups by # of votes in each group, largest-first

If all groups have exactly 1 close vote in them, the oldest (first) vote is used as the reason for closure. Otherwise, the first group in the list is used.

(this gets slightly more complicated for off-topic, but we can ignore that here)

Now, here's where it gets interesting: the grouping and sorting in steps #2 and #3 is stable - it won't change the order of votes within a group or between groups that have the same number of votes, and groups are created in the order their key first appears in the list. Since that list is sorted newest-first, the first group in the resulting list will be either the one with the most votes or the newest one with the most votes in the case of a tie. So clearly, the system works as it has been documented and the scenario you're describing cannot have occurred.

...Unless I lied about step #1. Which, it turns out, I did!

Seems it's a bit dodgy trying to store a vote and immediately retrieve it - sometimes it wouldn't be retrieved. So to fix that bug, the logic was changed to retrieve all previous votes, then store the new one, then add the new one to the list of retrieved votes and continue with the process.

...Only problem is, the vote gets added to the end of the list. Which was sorted newest-first.

And so you get what we saw here.

## 6-6-2018: fixed

The fix for the problem described above involved changing a call to `List<T>.Add(vote)` into one to `List<T>.Insert(0, vote)`. Also a comment for the next person to mess with this logic.

• "...Unless I lied about step #1. Which, it turns out, I did!" Are you telling us little lies? Commented Mar 1, 2018 at 18:43
• sweet, sweet lies, @Anne... (It probably won't surprise you to learn that I wrote this post as sort of a stream of consciousness as I researched this behavior) Commented Mar 1, 2018 at 18:45
• So basically, when sorting the votes newest-first, it actually puts the last vote last, while the first four in the sorting order are the first four that were cast, newest first? Commented Mar 1, 2018 at 19:00
• Right, @ano: 4,3,2,1,5 Commented Mar 1, 2018 at 19:01
• So how easy is it, from the technical side, to fix this? Commented Mar 1, 2018 at 19:02
• Pretty easy. But not high priority Commented Mar 1, 2018 at 19:02
• So would this be status-planned, status-deferred, or status-declined? Or status-reproduced? Commented Mar 1, 2018 at 19:03
• None of the above, @ano. We don't currently have a tag for whatever this is. Commented Mar 1, 2018 at 19:08
• status-ehhhhhh-it-kindaworks ;p Commented Mar 2, 2018 at 6:59
• Giving preference to the oldest vote in case of a tie doesn't seem logical anyway, considering that question could have been edited, and clarifying comments could have been added since that vote. In most cases, a more recent vote will be a better informed vote. The bug is an improvement on the original design.
– user315433
Commented Mar 2, 2018 at 18:37
• That bit is by-design, @FTP, although I can see the philosophical argument for changing it. In any case, 5 different close reasons is an extremely rare event; maybe happened a few dozen times in the entire history of SO. Commented Mar 2, 2018 at 18:46
• Comment goes like "Dear next person who mess with this logic, you'll have to confront Shog first"? Commented Jun 6, 2018 at 14:00
• Comment says something like "keep list sorted when adding not yet live vote"... Though now that I think about it, linking to this thread would've been more helpful. Oh well. That's why `blame` exists. Commented Jun 6, 2018 at 14:02