-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Getting continuation while ordering by oldest first repeats first article of continuation #25
Comments
Thanks for reporting. Let me do some testing and I'll get back to you shortly. |
Hey @cachapa, unfortunately I had no luck with reproducing of this bug. First thing I've added API spec to our internal testing system that checks how both reverse sorting and continuation works, and it showed that everything is working fine. Then I've tried to reproduce it with subscription ID that you mentioned, no luck again. However, it looks like you've marked some of its items as read, so I checked it w/o Regarding the issue itself: I assume that duplicated item causes confusion, but it probably should not, since there is a chance that you'll retrieve the same item with any other request. You can use unique item identifier to ensure items uniqueness in your local storage. I hope that this can help you. Let me know what you think. |
Thanks for taking your time to check on this. I'm still able to replicate this consistently, so I'm surprised you couldn't do it from your side. Here are two requests which for us always show the problem: First list:
Continuation:
For now, we've been able to get around this by doing exactly what you suggested: we check the id of the "border" articles and if they match, we remove the duplicate before joining the lists. Can you expand on the chance that we'll receive the same article in other requests? I'd prefer not doing these checks at all if possible, as they seem to be a bit hacky to me. We've not seen this issue in our implementation of other APIs. |
Thanks for detailed report. You're right, this issue was pretty rare and it was possible to reproduce only with exact set of given parameters. It's now fixed so you can get rid from your hack. I assumed that you're using local cache/storage to sync with our API. So, there might be case when you retrieved some items from subscriptions, and the same items are in other feeds like starred, etc. I'm not sure it's relevant, but it makes sense to cache/store items with unique ids anyways. |
I confirm this is fixed. |
We're getting 30 items at a time, and using continuation to get another batch of articles when the user reaches the end of the list.
When the order is newest first it works fine, but when we request oldest first (r=0), the first article of the list retrieved through continuation is a repeat of the last one from the previous list.
In testing, we managed to get around this by casting the continuation id to long and incrementing it before submitting, but this is a hack we'd rather not have to rely on.
Here's a sample request for Gizmodo:
The text was updated successfully, but these errors were encountered: