Skip to content

fix: Keep last read book from bouncing back to the old spot - #399

Open
RobinD42 wants to merge 1 commit into
van-geaux:mainfrom
RobinD42:fix/currently-reading-update
Open

RobinD42 wants to merge 1 commit into
van-geaux:mainfrom
RobinD42:fix/currently-reading-update

Conversation

@RobinD42

@RobinD42 RobinD42 commented Nov 4, 2026

Copy link
Copy Markdown
Contributor

Pull request

I noticed that after reading a book it would momentarily shift to the left side of the Currently reading shelf on Home, and then shift back to where it was. It seems it was refreshing to the old last-read value from BookOrbit instead of waiting until BookOrbit is fully updated with the new status.

Contributor checklist

  • The change is scoped to the related issue or feature discussion.
  • Tests and manual-validation status are documented.
  • No credentials, cookies, API keys, private server URLs, or generated local data are included.

Summary

Keep a book’s optimistic lastReadAtMillis update after reading until refreshed server data reflects it. A successful progress sync may precede the catalog endpoint showing the updated timestamp, which could otherwise move the book back down the Currently reading shelf.

Adds coordinator regression coverage for both stale catalog responses and server data that has caught up.

Verification

  • .\gradlew.bat :app:testDebugUnitTest — passed.
  • git diff --check — passed.
  • Manually verified on 2 devices

…book, so the just read book stays at the head of the list.
@van-geaux

Copy link
Copy Markdown
Owner

@RobinD42, I think the optimistic progress can still disappear too soon. The coordinator loads the Home shelves, then refreshes the catalog. If the catalog has the new lastReadAt but the Home shelf still has the old order, clearReflectedProgress() removes the local update and the old shelf is displayed, so the book can jump back.

We’ll take a few days to test this behavior before deciding on next steps. Thanks for your work on this!

@RobinD42

RobinD42 commented Nov 5, 2026

Copy link
Copy Markdown
Contributor Author

Yep, I did notice that 2 books (at the 4th and 5th positions IIRC) sometimes still swapped places after my change. I investigated a little with Copilot but didn't do any other changes related to it as I wasn't sure I understood how it is supposed to work. Maybe the catalog should just always be updated to match BookOrbit's Currently Reading order?

Anyway, here is the Copilot question and response in case it helps you:

I still see that sometimes books further down the Currently reading list are sometimes swapping positions a few seconds after returning to Home, as if the timestamp the app has still doesn't match what BookObit returns in that refresh. Is the app's catalog data getting properly updated in that case?

Not reliably. The app refreshes and persists the server’s catalog response, but it does not persist the app’s optimistic read timestamp into the catalog. So if BookOrbit returns an old or rounded timestamp, the catalog still has that value.

There’s also a likely reason the UI can revert: after a successful sync, the app clears its in-memory progress overlay when the server timestamp is within one second of the local timestamp. That can treat a slightly older, second-rounded timestamp as current. Once the overlay is cleared, sorting falls back to the timestamp in the refreshed catalog.

The relevant paths are refreshLibraryCatalog, which persists the server response, and clearReflectedProgress, which removes the local overlay. So the catalog data isn’t guaranteed to retain the newer local ordering when the server response lags.

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.

2 participants