When calling the /polls/voters.json endpoint, using pagination, we’ve found that the first call returns 25 users as expected, but the 2nd page returns 26 users, one of which was returned in the first call. This is consistent whenever there are over 25 users.
The problem is here in the poll plugin for discourse:
The offset is calculated assuming that postgress SQL is exclusive with a bound of the row using BETWEEN, when it is inclusive.
The first query actually returns 25, because the calculated rows actually start a 1, not 0.
WHERE pv.poll_id IN (:poll_ids)
/* where */
) v
ORDER BY digest, CASE WHEN rank = 'Abstain' THEN 1 ELSE CAST(rank AS integer) END, username
LIMIT :limit OFFSET :offset
SQL
Thanks for quick reply!
I’ll try to set up an env, didn’t wanna PR without testing. Anyone feel free to beat me to it. I’m not a ruby dev at all. I also don’t know about changing spec or tests.
Hilariously in the UI there is code that dumps the results into a set to bypass this bug.
It’s even more funny than that. I submitted a couple of very large PRs a while back to modernise the front end and add Ranked Choice.
The huge scale of those PRs definitely contributed to me missing this and back end fixes were not really in scope (though in the process of doing those PRs I did actually resolve a lot of issues that weren’t strictly for those PRs to fix)
I admit to matching that front end precedent that was set back in 2018 for ranked choice without really thinking about it . (Which you guys just also followed, albeit knowingly )
Amazing how workarounds can persist without the underlying issue being identified.