Fetch as many items as possible during the initial sync #306
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I remember encountering this issue when working on FreshRSS Android: the
n
query param forreading-list
endpoint limits the number of item that can be retreived and it defaults to a stupidely low value (20) when unset. This will prevent fetching items from feed that heven't published for some time. This is a problem for initial fetching since these feed will always appear empty. There's currently no way to force fetch those older items. Setting then
query parameter to a high value during initial fetch mitigates this issue. It doesn't resolve though, since there's still a chance that a server has more than 2 147 483 647 (which is the value ofInt.MAX_VALUE
on Android) items. I think there's some paging mecanism on this endpoint but I don't remember where it's documented.Note: IMHO
MAX_ITEMS
andMAX_STARRED_ITEMS
should be replaced byInt.MAX_VALUE
everywhere even when not doing initial fetch because the problem also risks to reproduce in the case where Readrops has performed an initial sync but hasen't synced in a sufficiently long time that the number of new items to process is higher thanMAX_ITEMS
orMAX_STARRED_ITEMS
. And this case, howerver unlikely, will be very tricky to debug. Theot
query parameter is already there to limit the number of results. I don"t think it is a good idea to limit it again withn
. At least not untilTimelineTab
has a bottom pull-to-refresh feature that force fetching older items.This should solve #282