fix(channels): close stray thread when the channel feed mounts - #4016
Conversation
The thread panel's open state (threadPanelStore.openByChannel) is route-independent, and nothing cleared it when the feed remounted — so feed → task → back to feed could repaint a task sidebar beside the feed. Feed and thread panel are mutually exclusive, so clear the channel's open-thread entry on feed mount. Generated-By: PostHog Code Task-Id: cdb544dd-fce7-4877-9c38-e91299400585
|
😎 Merged directly without going through the merge queue, as the queue was empty and the PR was up to date with the target branch - details. |
Generated-By: PostHog Code Task-Id: cdb544dd-fce7-4877-9c38-e91299400585
|
React Doctor found 2 issues in 1 file · 2 warnings. 2 warnings
Reviewed by React Doctor for commit |
adboio
added
the
Stamphog
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| useEffect(() => { | ||
| const open = useThreadPanelStore.getState().openByChannel[channelId]; | ||
| if (open) useThreadPanelStore.getState().closeThread(channelId); | ||
| }, [channelId]); |
There was a problem hiding this comment.
When the feed mounts with a stale thread ID, the initial render commits ThreadSidebar before this passive effect clears the store entry, causing the overlapping task panel to flash before disappearing.
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/ui/src/features/canvas/components/WebsiteChannelHome.tsx
Line: 140-143
Comment:
**Stale sidebar renders before cleanup**
When the feed mounts with a stale thread ID, the initial render commits `ThreadSidebar` before this passive effect clears the store entry, causing the overlapping task panel to flash before disappearing.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
Prompt To Fix All With AI### Issue 1
packages/ui/src/features/canvas/components/WebsiteChannelHome.tsx:140-143
**Stale sidebar renders before cleanup**
When the feed mounts with a stale thread ID, the initial render commits `ThreadSidebar` before this passive effect clears the store entry, causing the overlapping task panel to flash before disappearing.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "chore: drop restated comment from channe..." | Re-trigger Greptile |
|
Note 🤖 stamphog reviewed Greptile's unresolved P1 comment on WebsiteChannelHome.tsx (lines 140-143) is a valid, unaddressed technical concern: the cleanup runs in a passive effect after the first commit, so the stale sidebar still renders briefly before disappearing — the exact overlap bug this PR claims to fix isn't fully eliminated, and the added test can't catch it since RTL flushes effects synchronously.
Gate mechanics and policy version
|
stamphog
Bot
removed
the
Stamphog
Greptile P1: clearing the open-thread entry in a passive effect still committed ThreadSidebar for one frame, flashing the overlapping view. Snapshot the inherited entry during the first render, exclude it from the sidebar render, and clear the store in the effect for hygiene. Threads opened from this feed instance are unaffected. Generated-By: PostHog Code Task-Id: cdb544dd-fce7-4877-9c38-e91299400585
The ref-based version split the same fact across render, a mutable ref, and an effect. A lazy useState initialiser captures the inherited entry once; the render excludes it and one effect clears the store. Same behavior, one less moving part. Generated-By: PostHog Code Task-Id: cdb544dd-fce7-4877-9c38-e91299400585
adboio
added
the
Stamphog
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Contained UI fix to a stale thread-sidebar rendering bug, with tests; the prior reviewer's stale-render flash concern is directly addressed by the diff's render-time suppression logic (hence marked outdated), and this isn't risky territory.
- Author wrote 0% of the modified lines and has 12 merged PRs in these paths (familiarity MODERATE).
- 👍 on the PR from greptile-apps[bot].
Gate mechanics and policy version
| Gate | Result | |
|---|---|---|
| prerequisites | ✓ | all clear |
| deny-list | ✓ | no deny categories matched |
| size | ✓ | 17L, 1F substantive, 133L/2F incl. docs/generated/snapshots — within ceiling |
| tier | ✓ | T1-agent / T1c-medium (133L, 2F, single-area, fix) |
| stamphog 2.0.0b3 | .stamphog/policy.yml @ 5ac5892 · reviewed head 61fb7c1 |
1 participant
Problem
Users could end up looking at a channel's feed with a specific task's sidebar still docked on the right — two mutually exclusive views rendered at once.
Changes
The thread panel's open state (
threadPanelStore.openByChannel) is route-independent: it only changes viaopenThread/closeThread, and nothing cleared it when the feed remounted. So feed → open full task → back to feed left the stale entry in place, andWebsiteChannelHomere-mounted theThreadSidebarbeside the feed.Fix: when a channel's feed mounts, clear any open-thread entry for that channel (
closeThread). Feed and thread panel are mutually exclusive, and the feed rendering is the only reliable signal that no thread is active — the task page's own sidebar is route-driven and unaffected.How did you test this?
WebsiteChannelHome.test.tsx: mounts the feed with a thread open and asserts the sidebar doesn't render and the store entry is cleared. Fails against pre-fix code, passes with the fix.packages/uicanvas suite: 290/290 pass.biome checkandtsc --noEmitclean on the changed files.Automatic notifications
Created with PostHog Code