Hold channel loading state until the feed is complete so it opens at the latest message

[adboio]

Problem

Opening a channel from the sidebar feels slow and doesn't start you at the most recent message. The feed scroller (ChatMessageScrollerProvider defaultScrollPosition="end") applies its initial end-scroll exactly once, as soon as it has any content — and by design it never re-scrolls when more rows arrive (no forced scroll). Today the scroller mounts around partial content: the synthesized "joined" opener renders the moment the backend channel resolves, while the task cards and system messages are still fetching (the loading gate also ignored useChannelFeedMessages' loading state). The one-shot end-scroll spends itself on that near-empty list, so the real cards land off-screen below.

Changes

• WebsiteChannelHome: fold useChannelFeedMessages' isLoading (already returned, previously unused) into the feed loading gate.
• ChannelFeedView: scroll to the latest message on channel switch — channel-to-channel navigation swaps content without a route remount, so the scroller's one-shot defaultScrollPosition only covers the channel it mounted with and a revisited channel kept the previous channel's scroll offset (often the top). Implemented as a ref on the scroller viewport plus a layout effect keyed on the channel id that sets scrollTop = scrollHeight before paint; no remount, no extra components.
• ChannelFeedView: hold the loading spinner while the feed is still loading even if some entries already exist, so the scroller mounts once with the complete feed and its initial end-scroll lands at the latest message. Optimistic pending kickoffs still bail out of the spinner immediately, and warm reopens render instantly from cache with no repeat spinner.

No new scroll code — verified against the scroller engine source that defaultScrollPosition="end" handles the landing correctly once the mount isn't premature.

Why: raised in project-bluebird — opening a channel should render at the most recent message immediately instead of showing a half-loaded feed scrolled to the top.

How did you test this?

• pnpm --filter @posthog/ui typecheck and pnpm --filter @posthog/ui test (200 files / 1755 tests pass), pnpm lint clean on changed files.
• Scroll/paint timing is best eyeballed live — worth a quick check in the running app that a cold channel open lands at the bottom and a reopen shows no spinner.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

---

Created with PostHog Code

[trunk-io]

😎 Merged successfully - details.

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit d318994.}

[github-actions]

Low-risk UI fix: holds the channel loading state until the full feed is available so the one-shot scroll-to-end lands correctly, plus a useLayoutEffect to handle channel switches without remount. Changes are confined to view layer, touch no business logic, API contracts, or data models.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/ui/src/features/canvas/components/ChannelFeedView.tsx:714
**Pending Row Mounts Incomplete Feed**

If a kickoff is submitted while the initial tasks or system messages are still loading, `pending.length > 0` mounts the scroller around partial content and consumes its one-shot end scroll. The remaining rows then arrive without changing `channelId`, so neither the default scroll nor the layout effect runs again and the channel can open above its latest message.

_{Reviews (1): Last reviewed commit: "Simplify channel-switch scroll to an inl..." | Re-trigger Greptile}

[greptile-apps]

Pending Row Mounts Incomplete Feed

If a kickoff is submitted while the initial tasks or system messages are still loading, pending.length > 0 mounts the scroller around partial content and consumes its one-shot end scroll. The remaining rows then arrive without changing channelId, so neither the default scroll nor the layout effect runs again and the channel can open above its latest message.

Rule Used: In cases where there are multiple states to handle... (source)

Learned From
PostHog/posthog#32610

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/ui/src/features/canvas/components/ChannelFeedView.tsx
Line: 714

Comment:
**Pending Row Mounts Incomplete Feed**

If a kickoff is submitted while the initial tasks or system messages are still loading, `pending.length > 0` mounts the scroller around partial content and consumes its one-shot end scroll. The remaining rows then arrive without changing `channelId`, so neither the default scroll nor the layout effect runs again and the channel can open above its latest message.

**Rule Used:** In cases where there are multiple states to handle... ([source](https://app.greptile.com/posthog-org-19734/-/custom-context?memory=b99946fe-4cce-4bff-bdc0-8480d200548a))

**Learned From**
[PostHog/posthog#32610](https://github.com/PostHog/posthog/pull/32610)

How can I resolve this? If you propose a fix, please make it concise.

New commits pushed (delta classified non_trivial_delta) — stamphog approval dismissed; re-review running automatically.

[github-actions]

Small, view-layer-only scroll fix. No business logic, API contracts, data models, or infrastructure involved. The bot-flagged edge case about pending rows during loading is a scroll-position UX concern, not a showstopper.

New commits pushed (delta classified non_trivial_delta) — stamphog approval dismissed; re-review running automatically.

[github-actions]

Pure view-layer scroll fix confined to two UI components. The greptile bot comment about pending rows is from an older commit and describes a narrow edge-case scroll-position UX quirk — not a correctness, data, or crash risk. The useLayoutEffect dependency on isLoading means the scroll-to-end fires when loading completes, which covers the primary scenario.