Looks like there's a slight bug here...
Normally, the way consensus is determined when closing is by...
- Sorting all relevant close votes, newest-first
- Grouping those sorted votes by close reason
- 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.
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.