If a later Timeline page fails to load, you lose everything you already had. src/pages/timeline/use-timeline-page.ts:108-116 catches the failure and calls:
setState({
kind: "error",
code: "failed",
message: "Timeline records could not be loaded.",
retryable: true,
})The page state is a single union ({ kind: "loading" } | TimelineReadResult, L14), so replacing it with an error throws away the records already on screen. Scroll through a few hundred records, hit one flaky read on page four, and you are back to an empty error page with no way to retry just the page that failed.
The initial-read failure at L51-57 does the same thing, and there it is the right call. There is nothing to preserve yet. The difference is that loadMore has a good ready state in hand and discards it.
Keep the loaded timeline on screen and report the failure next to the pagination controls instead. "Load more" should retry the same page it failed on, and a successful retry should clear the message. The retry bookkeeping you need is already there: loadMoreAttemptRef (L21) and the AbortController in loadMoreControllerRef (L22) guard against a stale response landing after a newer attempt, so follow that pattern rather than adding a second mechanism.
Leave the initial-read behavior alone.
runs typecheck and vitest. src/pages/timeline/index.test.tsx already has coverage for the page to model new cases on. I will look at whether previously loaded records survive a failed page four, and whether retrying then appends without duplicating anything.
If a later Timeline page fails to load, you lose everything you already had.
src/pages/timeline/use-timeline-page.ts:108-116catches the failure and calls:The page state is a single union (
{ kind: "loading" } | TimelineReadResult, L14), so replacing it with an error throws away the records already on screen. Scroll through a few hundred records, hit one flaky read on page four, and you are back to an empty error page with no way to retry just the page that failed.The initial-read failure at L51-57 does the same thing, and there it is the right call. There is nothing to preserve yet. The difference is that
loadMorehas a goodreadystate in hand and discards it.Keep the loaded timeline on screen and report the failure next to the pagination controls instead. "Load more" should retry the same page it failed on, and a successful retry should clear the message. The retry bookkeeping you need is already there:
loadMoreAttemptRef(L21) and theAbortControllerinloadMoreControllerRef(L22) guard against a stale response landing after a newer attempt, so follow that pattern rather than adding a second mechanism.Leave the initial-read behavior alone.
runs typecheck and vitest.
src/pages/timeline/index.test.tsxalready has coverage for the page to model new cases on. I will look at whether previously loaded records survive a failed page four, and whether retrying then appends without duplicating anything.