Keep a context's star and task history after renaming it#3480
Conversation
Renaming a context (channel) silently dropped it from the Starred section and made its task history look empty. Both stem from name-keyed links that go stale on rename: the star is a desktop shortcut whose `ref` is the channel path, and the task feed resolves its backend channel by name. - Re-point the star's shortcut to the new path after a rename (create new, delete stale) via `useRepointChannelStar`. - Rename the matching backend task channel to the new name so the feed/history follows, using the existing task-channel PATCH endpoint, via `useRenameBackendChannel` (adds `renameTaskChannel` to the API client). - Optimistically update the channels cache on rename so the folder name and the backend channel name flip together, avoiding a transient empty duplicate. Both follow-ups are best-effort and never throw, so a hiccup can't turn a successful rename into an error. Generated-By: PostHog Code Task-Id: 795ba9eb-2d2f-432c-a0a3-f0020bb87ccb
|
Merging to
After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here |
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
The backend task-channel rename and the star re-point are independent (they touch different caches and resources) and both do their synchronous cache work before their first await, so running them concurrently doesn't affect the rename race. Addresses the React Doctor async-parallel finding. Generated-By: PostHog Code Task-Id: 795ba9eb-2d2f-432c-a0a3-f0020bb87ccb
|
Reviews (1): Last reviewed commit: "Run rename follow-ups (backend channel +..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| if (!existing && !cached) { | ||
| try { | ||
| existing = findPublic(await client.getTaskChannels()); | ||
| } catch { | ||
| return; | ||
| } | ||
| } | ||
| if (!existing) return; // No backend channel/history to carry over. |
There was a problem hiding this comment.
When the cache is populated but does not yet contain the old task channel, this path does not fetch the current list and silently returns. This can happen when another tab created the task channel after the last poll; renaming then leaves its history under the old name while the new folder resolves to an empty channel.
|
|
||
| const staleId = existing.id; | ||
| const previous = existing; | ||
| // Optimistically rename in-cache so the feed's name lookup resolves to | ||
| // this channel immediately once the folder name flips. | ||
| queryClient.setQueryData<TaskChannel[]>(TASK_CHANNELS_QUERY_KEY, (prev) => | ||
| prev?.map((c) => | ||
| c.id === staleId ? { ...c, name: newNormalized } : c, | ||
| ), | ||
| ); |
There was a problem hiding this comment.
If the 30-second task-channel query is already in flight, its old server response can overwrite this optimistic name before the PATCH completes. useBackendChannel(newName) then sees no match and can resolve or create an empty channel, splitting the feed from the original history.
| queryClient.setQueryData<TaskChannel[]>( | ||
| TASK_CHANNELS_QUERY_KEY, | ||
| (prev) => prev?.map((c) => (c.id === staleId ? previous : c)), | ||
| ); |
There was a problem hiding this comment.
This rollback restores the captured object without checking whether the same channel has changed since this request began. If another rename or a poll updates that entry before this PATCH fails, the older failure restores the obsolete name and can make the current folder resolve to a different empty feed.
1 participant
Problem
Renaming a context (channel) in the desktop app had two surprising side effects reported by users:
Neither is data loss — the tasks were still on the server — but both make a rename feel destructive.
Why: both the star and the feed are linked to a context by name, and those links go stale on rename. The star is a per-user desktop shortcut whose
refis the channel's path (its name). The task feed lives on a separate backend "task channel" that the UI resolves by name on every render — so after a rename it no longer matched and a new, empty channel was resolved-or-created.Changes
useRepointChannelStarhook.useRenameBackendChannel, plus arenameTaskChannelmethod on the API client).Both follow-ups are best-effort and never throw, so a hiccup in either can't turn a successful rename into an error.
How did you test this?
useRepointChannelStar: moves a starred channel's shortcut to the new path; no-ops when unstarred.useRenameBackendChannel: renames the matching public channel (normalized), cache and fetch-fallback paths, personal/unchanged no-ops, and optimistic rollback on PATCH failure.pnpm --filter @posthog/api-client typecheckandpnpm --filter @posthog/ui typecheck— clean.Automatic notifications
Created with PostHog Code