Ich dachte, ich versuche mich mal an meinem ersten Beitrag, aber es scheint, als wäre es doch etwas komplizierter als erwartet. 
Ich habe einen Draft-PR hochgeladen: FIX: do not return duplicates from /polls/voters.json by clechasseur · Pull Request #1 · clechasseur/discourse · GitHub
In diesem PR habe ich zuerst Tests hinzugefügt, die das Problem reproduzieren, dann habe ich Robs einfache Lösung angewendet und die Tests haben bestanden.
Ich habe auch die elegantere Lösung ausprobiert (die, die ich bevorzugt hätte), aber obwohl sie doppelte Wähler verhindert, ändert sie auch, welcher Wähler auf welcher Seite zurückgegeben wird, einschließlich der ersten, was potenziell als Breaking Change angesehen werden könnte (abhängig davon, wie das Frontend damit umgeht - ich habe es noch nicht nachgesehen).
Wenn ich jedoch einen Schritt zurücktrete, frage ich mich, was die wahre Bedeutung des limit-Parameters ist, wenn man diesen Endpunkt aufruft - er begrenzt nicht wirklich die Anzahl der insgesamt zurückgegebenen Wähler, sondern nur die Anzahl der Wähler, die für jede Umfrageoption zurückgegeben werden. Diesen Effekt sehen Sie in dem Test, den ich für die Multiple-Choice-Umfrage hinzugefügt habe hier - die erste Seite ist tatsächlich auf 2 Wähler pro Option begrenzt, aber insgesamt werden drei verschiedene Wähler zurückgegeben (verteilt auf die Optionen). Wenn man zur eleganten Lösung wechselt (d. h. LIMIT :limit OFFSET :offset verwendet), wird das limit auf die Gesamtzahl der Stimmen und nicht der Wähler angewendet. Ich bin mir nicht zu 100 % sicher, ob das besser oder intuitiver ist.
Wie auch immer, ich bin neu hier und vielleicht denke ich zu viel nach. Die einfache Lösung entfernt doppelte Wähler und richtet nicht zu viel Schaden an, daher könnte sie der richtige Weg sein. Ich warte auf Input, bevor ich einen PR an das Haupt-Repository sende.
–
Nebenbei bemerkt, glaube ich, dass es in diesem Teil des Codes einen weiteren Fehler gibt. Die Abfrage zum Laden der Wähler ist nach Digest, Rang und Benutzername sortiert - aber beim Sortieren nach Rang wird diese Bedingung verwendet:
CASE WHEN rank = 'Abstain' THEN 1 ELSE CAST(rank AS integer) END
Allerdings entspricht 'Abstain' tatsächlich Rang 0 und nicht 1 - Rang 1 kann auch als '1' zurückgegeben werden. Dies macht die Sortierung potenziell nicht deterministisch über Abfragen hinweg, was bedeutet, dass es je nach Anzahl der Wähler und dem verwendeten limit-Wert möglich sein könnte, Wähler bei paginierten Abfragen tatsächlich zu übersehen. In meinen neuen Tests musste ich die zurückgegebenen Wähler sortieren, um die nicht-deterministische Natur zu umgehen. (Da sie nicht deterministisch ist, gehe ich davon aus, dass sie in einem Test nicht leicht reproduzierbar ist, aber ich kann es versuchen…)