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. – Sonic the Curiouser Hedgehog Dec 17 '17 at 12:25
• Dupes aren't really "closes" though, so they may win out. – Catija Dec 17 '17 at 18:45
• @Shog what exactly was fixed? Can you elaborate? – Shadow The Vaccinated Wizard Jun 6 '18 at 13:48
• See answer edit, @Shadow – Shog9 Jun 6 '18 at 13:59
• @Shog well, I did wait few minutes before asking... you could edit your answer before adding the tag... ;) – Shadow The Vaccinated Wizard Jun 6 '18 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... – Shog9 Jun 6 '18 at 14:09
• – gnat Nov 29 '19 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? – Anne Daunted GoFundMonica Mar 1 '18 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) – Shog9 Mar 1 '18 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? – Sonic the Curiouser Hedgehog Mar 1 '18 at 19:00
• Right, @ano: 4,3,2,1,5 – Shog9 Mar 1 '18 at 19:01
• So how easy is it, from the technical side, to fix this? – Sonic the Curiouser Hedgehog Mar 1 '18 at 19:02
• Pretty easy. But not high priority – Shog9 Mar 1 '18 at 19:02
• None of the above, @ano. We don't currently have a tag for whatever this is. – Shog9 Mar 1 '18 at 19:08
• status-ehhhhhh-it-kindaworks ;p – Journeyman Geek Mar 2 '18 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 Mar 2 '18 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. – Shog9 Mar 2 '18 at 18:46
• Comment goes like "Dear next person who mess with this logic, you'll have to confront Shog first"? – Shadow The Vaccinated Wizard Jun 6 '18 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. – Shog9 Jun 6 '18 at 14:02