fix(mobile): resolve a stickied wiki page by book+id, not id alone - #11
Merged
Merged
Conversation
Tapping a Home-pinned wiki page intermittently showed "Page not found" and dropped into a blank editable page — reported for a grocery-list page in a shared book. The page was never missing server-side. Cause: the pin routed to #wiki/<pageId> (id only), and openPage discovered the book by scanning the CURRENTLY ACTIVE book's page list (refresh only loads the active book, and picks "most recent" when none is set). So whenever the app reopened onto a different book than the page lives in, the id was never in the loaded list, the fallback refresh pulled the wrong book, and the user landed on "Page not found" + blank body. Hence intermittent: fine when the page's book happened to be active, broken otherwise. The backend already sends what was needed — HomePin carries book_slug and the pins query populates it for every book. Pure client fix: - openPage now accepts "bookSlug/pageId" as well as bare "pageId"; given a book, it selects that book and loads its pages BEFORE resolving the id. Bare-id (old stickies, other deep links) still works via the scan. - The Home wiki pin, the page-list row, the after-create nav, and the wiki-link nav all qualify the route with the book slug they already know. parseRoute needs no change: detail already keeps everything after the tab. Regression test in mobile.spec.ts (runs under the Pixel 7 mobile project): pin a page in book A, select book B in the UI, tap the pin, assert it opens A's page and the route is book-qualified rather than the "Page not found" blank.
The first cut asserted book B gained is-active after a click, but books list orders by updated_at DESC and B (its page created last) was already the default active book — so the click was a no-op, the class never changed, and the test failed in setup. Worse, it meant the scenario under test was never exercised: the bug needs the pinned page book (A) to NOT be active. Now: open the wiki tab, click B only if A is the active card, then poll until A is definitively not active. That is the real precondition and it is robust to whichever book defaults active. The fix under test is unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Tapping a Home-pinned wiki page intermittently showed "Page not found" and dropped into a blank editable page — reported for a grocery-list page in a shared book. The page was never missing server-side.
Cause: the pin routed to #wiki/ (id only), and openPage discovered the book by scanning the CURRENTLY ACTIVE book's page list (refresh only loads the active book, and picks "most recent" when none is set). So whenever the app reopened onto a different book than the page lives in, the id was never in the loaded list, the fallback refresh pulled the wrong book, and the user landed on "Page not found" + blank body. Hence intermittent: fine when the page's book happened to be active, broken otherwise.
The backend already sends what was needed — HomePin carries book_slug and the pins query populates it for every book. Pure client fix:
Regression test in mobile.spec.ts (runs under the Pixel 7 mobile project): pin a page in book A, select book B in the UI, tap the pin, assert it opens A's page and the route is book-qualified rather than the "Page not found" blank.