Любопытный Код: “Система подсчёта места чата в общем рейтинге всегда работала как-то по…”

Система подсчёта места чата в общем рейтинге всегда работала как-то подозрительно, хотя и была внимательно покрыта тестами.
И в очередной раз, обратив внимание на то что у чата, который поймал двух котов сообщение

Ваш счёт лучше чем у 92.4% чатов!

А у того, который поймал 4х

Ваш счёт лучше чем у 72.7% чатов!

Я решил докопаться до истины, развернул дамб БД локально и начал дебажить.

SELECT cue.chat.id, sum(cue.result)
FROM CatUserEvent cue
WHERE cue.date > :fromDate
  AND cue.catType != 0
GROUP BY cue.chat.id

Вот так выглядит SQL запросик, выглядит правильно и логично. Отсеиваем по типу баллы за картинки(шут знает, за что их дали) и группируем по чату.
Делаю выборку, залезаю в результаты и наблюдаю, что чат, который должен был получить 2 бала, имеет 8 😳
Смотрю, что ж там за события такие, что аж 8 набралось, и вижу результаты:

CLOSE
CAT1
CAT1

А теперь внимание, тип события хранится в енуме, который сохраняется через ordinal.

public enum CatRequestVote implements CallbackItem {
    NOT_CAT(0, "crv0", "Любопытный Кот сбегает от "),
    CAT1(1, "crv1", "Любопытный Кот убегает к "),
    CAT2(2, "crv2", "Два кота засчитано игроку "),
    CAT3(3, "crv3", "Целых три кота засчитано "),
    CAT4(4, "crv4", "Целых 4 кота засчитано "),
    LIKE_PHOTO(-1, "crvl", null),
    TIMEOUT(0, "crv0", "Любопытный Кот не дождался "),
    CLOSE(0, "crv0", null);
}

И как вы видите CLOSE находится на 8 месте и имеет индекс 7, т.е. 7+1+1=9. Удивление! Тайна раскрыта, правим запрос:

SELECT cue.chat.id, sum(cue.result)
FROM CatUserEvent cue
WHERE cue.date > :fromDate
  AND cue.catType != 0
  AND cue.result <= 4
GROUP BY cue.chat.id

Буду меньше краснеть.