Skip to content

Fix lazy load pagination stalls and null API response crashes - #150

Open
courville wants to merge 2 commits into
tt-rss:masterfrom
courville:dev/fixLazyLoading
Open

Fix lazy load pagination stalls and null API response crashes#150
courville wants to merge 2 commits into
tt-rss:masterfrom
courville:dev/fixLazyLoading

Conversation

@courville

Copy link
Copy Markdown
Contributor
  • Fix lazy load pagination stalls in adaptive-mode and Fresh feeds when mark-as-read-on-scroll is enabled — shrinking unread counts were being mistaken for exhausted feeds.
  • Guard against crashes when the API returns a null response in feed/subscribe screens.

getSkip() used numAll (total articles fetched this session) as the
skip offset for adaptive mode once any unread articles existed, and
unconditionally for all other view modes. With mark-as-read-on-scroll
active, feeds whose membership is unread-only (adaptive mode while
unread remain, the "unread" view mode, and the Fresh virtual feed)
shrink as articles are marked read, so numAll overshoots the feed's
actual remaining count. The server then returns 0 articles and lazy
load is permanently disabled.

Use numUnread as the skip offset for all of these unread-only cases,
falling back to numAll once no unread articles remain (adaptive) or
for view modes with stable membership (marked/published/search).

Also stop disabling lazy load on firstIdChanged during append: mark-
as-read-on-scroll changes the feed's first_id on the server, so
firstIdChanged is set on every append response once scrolling starts,
which permanently disabled lazy load after the first pagination
request. Only treat it as a real feed-structure change on fresh
(non-append) loads.
performRequest() can return null on HTTP error responses or after a
caught exception, but several callers parsed the result unconditionally,
risking a NullPointerException when a request fails at the
transport/API level instead of via an explicit ApiError. Skip parsing
when result is null in SubscribeActivity, FeedsModel, and
RootCategoriesModel; the corresponding error is already surfaced via
the existing m_lastError/toast handling.
@courville

Copy link
Copy Markdown
Contributor Author

Please do not merge yet: I still noticed a lazy loading issue that deserves attention.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant