[pratikbuilds]

useHistoryWindow keeps a window of the latest items, adds earlier ones as the reader nears the top, freezes while the reader has scrolled away and trims back once they return to the end. It works with history the host pages in asynchronously, and the item in view stays put within a pixel as earlier items load. ConversationEarlier marks the top with a loading state and a retry when a page brings nothing. The doc comment records why this windows rather than virtualizes, and its ceiling.

Stacked on #121: review only this commit. Part of #94.

Notes for review

• stalled only applies while the window starts at the first held item (the only place the host is asked); a failed or empty page never blocks revealing items already held above the window.
• A page that settles while the chat is hidden under still lands (no unmount-only guard).
• Retry keeps focus: the marker takes focus while loading, returns it to the button if the retry stalls again, and hands it to the log when the last page lands and the marker goes away.
• The hook's own captureAnchor/restoreAnchor are covered by a cancel-out test (append + trim of equal height, so nothing resizes); it drifts 63px without them.
• The hook tests mount a small host component instead of using renderHook (src/test/render-hook.tsx), because renderHook has no wrapper option and the hook has to run inside a <Conversation> next to a mounted ConversationContent. They still go only through the hook's public API.

Verification

• This commit passes bun run typecheck and bun run lint on its own (the stack is checked commit by commit).
• At the top of the stack: bun run check, bun run build, bun run dep-guard, bun run contrast-test and bun run test:e2e (Playwright specs and the Storybook axe sweep in light and dark) pass.

Closes #100

[TheGreatAxios]

Automated multi-agent review: independent review + second-agent validation; only confirmed items listed. The hook itself is well-built and the windowing-ceiling doc is real; one verified race below.

Verified (executed harness running the real hook + real engine)

• The render-phase trim reads the rAF-throttled context atBottom: an append committing between the reader's scroll-up and the engine's per-frame pass removes the first shown item while the reader is scrolled up — violating the plan's hard constraint "never removes items while the reader is scrolled up" (src/hooks/use-history-window.ts:156-162 vs src/ui/conversation.tsx:389-399; a deterministic ordering harness reproduces it, and a frame-first control run proves nothing is removed when ordering is safe). Fix shape: gate the trim on a fresh position signal — trim in the subscribeScroll listener when snapshot.distanceFromEnd <= threshold, or read the last snapshot's distance from a ref in the render-phase trim. The suggested regression test currently fails on this code.

Minor

• e2e/history-window.spec.ts:3-51 duplicates e2e/conversation.spec.ts:3-44's harness helpers line-for-line — extract a shared e2e/ helper before the next PR copies it.
• A sync throw from onLoadEarlier is settled then rethrown out of reachStart(), which runs inside the marker's IntersectionObserver callback → uncaught exception in an observer callback (use-history-window.ts:246-253). Document, or route the rethrow through settled state only.
• nits: the hook harness differs from the plan's renderHook prescription without a stated deviation (add a PR-body note); conversation-earlier.tsx:92-101 hand-writes the ref-merge idiom.

[pratikbuilds]

Thanks for the review. Here's what happened to each point.

Fixed

1. A new message could remove the oldest one while the reader was scrolled up (the verified race)

• The problem: this was slightly wider than the trim alone. A message arriving in the same frame the reader started scrolling up made the window slide, because its "at the bottom" signal was one frame old.
• The fix: a new message is now added with nothing removed. A layout effect then trims the window as before, but it first checks whether the view has moved up since the last frame, and if so leaves everything in place.
• Tests: a unit test, "an item that lands before the frame the reader left in removes nothing". In a real-browser run, the first message used to change every time and now stays put.

2. The two e2e specs had duplicate helpers (minor)

• The fix: they now share e2e/conversation-helpers.ts.

3. A loader that throws crashed inside the observer (minor)

• The fix: if onLoadEarlier throws, the window stalls the same way it does for a rejected promise, and the error is reported once with reportError.

Not changed, and why

• The hand-written ref merge: the shared helper is private to another PR's file, so I left this one.
• Not using renderHook: I'll add a note about this to the PR description.

Commit: fix(conversation): hold the history window until the view is read

[TheGreatAxios]

Review · Request changes

Adds useHistoryWindow and ConversationEarlier. The window holds its tail while a scroll has not been read yet, except when the trim anchor disappears in the same update that grows the list.

Findings

• src/hooks/use-history-window.ts:72 — A missing through id slides the window during render, before the scroll pass can freeze it. When start.kind === "latest" and start.through is gone, startIndex returns items.length - windowSize. The layout effect at :204-211 only skips a later setState; it does not undo that fallback, and the next snapshot freezes the slid start. With 300 items, a window of 120 trimmed through r299, and a scroll that has moved but not yet been read, replacing r299 and appending r300 in one update drops r180. The pinned-start path already keeps the first surviving id of the previous window (:78-80). through should do the same when it is missing, instead of jumping to the new tail.

[pratikbuilds]

Thanks for the review. It's fixed.

1. A missing through id slid the window during render

• The fix: when the item the window was trimmed through is gone, the start falls back the same way a missing pinned id does. It goes to the first item of the previous window that still exists, and only goes to the latest windowSize items when none does. At the bottom, the next commit trims back, as it does after a plain append.
• Tests:
  • "an id swapped at the end as the reader leaves removes nothing" failed before the fix: the window started at r181 instead of r180.
  • "an id swapped at the end at the bottom still slides the window" checks that the bottom case still trims to 120 items.

Commit: fix(conversation): keep the window start when the last id is swapped

[pratikbuilds]

Round 3 fixes

A fresh review pass over the stack turned up the points below; each is fixed in a new commit at the end of this branch, and the stack is rebased onto it.

• 0ef713e: Only the reader's own scroll froze the window, so after a scrollToItem jump, a focus move or find-in-page, the next new item could trim the item the reader jumped to. Any move up away from the end now freezes it; content growing below a still view still slides.
• e43ba72: startIndex read previousWindow.current during render. The last slice now lives in the hook's state, and the scroll listener no longer reads a ref inside a state updater.
• 2e3be38: The onLoadEarlier doc now says a synchronous throw is reported through reportError and a rejection is left to the host.
• 78de4e3: React 18 refs: components that read ref from props only receive it on React 19, while the peer range allows ^18.2.0. They are now wrapped in forwardRef, so a host ref reaches the element on both; the peer range is unchanged. Covers ConversationEarlier.

bun run check and dep-guard pass on every branch of the stack, and the full e2e suite passes at the top of the stack (163/163, including the stories axe sweep). Each behaviour fix comes with a test that fails without it; the forwardRef tests can only guard, since the suite runs on React 19.

Superseded by the completed stacked review; blocking fixes were addressed and the rebased stack is being landed.

[corbits-triage]

Triage: In progress

Triage is waiting for CI to finish before it decides. This comment shows the verdict once it has.