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
nquery param forreading-listendpoint 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 thenquery 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_VALUEon Android) items. I think there's some paging mecanism on this endpoint but I don't remember where it's documented.Note: IMHO
MAX_ITEMSandMAX_STARRED_ITEMSshould be replaced byInt.MAX_VALUEeverywhere 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_ITEMSorMAX_STARRED_ITEMS. And this case, howerver unlikely, will be very tricky to debug. Theotquery 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 untilTimelineTabhas a bottom pull-to-refresh feature that force fetching older items.This should solve #282