This is a critical bug. Please read carefully.
So, I am paging through users with rep min 99 descending and am getting many duplicate records in subsequent pages.
The total user count has not changed for the site and it is 12am so I have to imagine that there is not enough rep activity to shift 100's of users 100's of places in the 1/5 of a second it takes me to get the next page.
Something is hinky.
The way I qualified this as a bug is with the dupe filter I had emplaced to catch the very, very slim chance that a user loses rep or enough users pass him just as I am getting the next page and he ends up on the next page as well.
This should be a very infrequent occurrence.
In any case, I catch the dupe and go and get the original, compare them, they are the same, I examine the raw json and sure enough, they are in the json. and in no particular order.
Then I notice that they all have the same rep. In the case of the sample urls shown, 101.
The creation dates are unique.
It appears that the sort is on a single field, reputation, and is non-repeatable, making the paging operation unreliable.
Consider - I can catch an arbitrary number of duplicates in subsequent pages, but what about the reciprocal number of items that were replace by the dupes? Are they going to be in the next page or did they get shifted behind me while I was paging?
In any case, the sort should not be on a single field that is not unique, like reputation.
To make a sort like this reliable you have to back your reputation sort up with perhaps creation_date and to avoid any problems with mass creations follow up with display_name.
so, here is some pseudo-sql that would result in a reliable sort for the query shown.
select * from users
where rep < int.max and rep > 99
order by rep desc, creation_date , display_name
As it is, the results are unusable.
I would hope that this can serve not only as a bug report on this particular route and sorting but also as a heads up that all permutations need to be checked for expected behavior.
samples
Of course these urls will return slightly different data as time goes on, but I have confirmed and repeated these results many times.
http://api.stats.stackexchange.com/1.0/users?max=2147483647&min=99&page=1&pagesize=100 user_id (you can pull the url yourself to see the json) = = = 8 5 74 159 88 87 36 61 13 90 28 41 69 81 62 66 68 190 174 56 191 55 23 138 6 217 38 183 72 229 54 252 131 237 75 114 71 80 171 198 175 157 173 58 169 57 85 59 209 220 184 181 179 177 176 170 164 163 161 160 156 155 153 152 147 143 141 35 33 30 29 21 19 18 16 12 10 7 4 3 2 53 51 50 43 27 65 64 135 134 102 94 84 129 127 126 123 122 121 116 http://api.stats.stackexchange.com/1.0/users?max=2147483647&min=99&page=2&pagesize=100 user_id (these are the dupes) = = = 53 7 2 3 4 16 18 19 21 27 10 12 29 30 33 35 84 94 102 67 76 116 121 122 123 126 127 129 141 143 147 152 153 155 156 103 60