🪤 fix: Reload Messages When Reopening a Chat from a Non-Chat Route#13501
Conversation
…t route navigateToConvo now removes the target conversation's cached messages before fetching, so a freshly-mounted ChatView refetches them. clearMessagesCache leaves a left conversation cached as [], and the messages query's refetchOnMount: false treats that empty array as valid — so returning to the conversation from a route where ChatRoute was unmounted (e.g. /projects) left the chat stuck on an empty cache with no /api/messages request.
There was a problem hiding this comment.
Pull request overview
Fixes a navigation edge case where reopening a previously visited conversation from a non-chat route (e.g. /projects) could leave ChatView stuck on a loading spinner because the messages query never refetched after clearMessagesCache left an empty-but-defined cache ([]).
Changes:
- Remove the target conversation’s messages query from the React Query cache during
navigateToConvoto ensure a fresh mount triggers the initial messages fetch. - Add inline documentation explaining why removal (vs invalidation) is required given
refetchOnMount: false.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
danny-avila
changed the title
|
@codex review |
GitNexus: 🚀 deployedThe |
|
Codex Review: Didn't find any major issues. Bravo. ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
…anny-avila#13501) navigateToConvo now removes the target conversation's cached messages before fetching, so a freshly-mounted ChatView refetches them. clearMessagesCache leaves a left conversation cached as [], and the messages query's refetchOnMount: false treats that empty array as valid — so returning to the conversation from a route where ChatRoute was unmounted (e.g. /projects) left the chat stuck on an empty cache with no /api/messages request.
Summary
Fixes a bug where clicking a previously-visited project chat from the sidebar while on the
/projectspage leaves the chat stuck on a loading spinner — the messages query never fires.Reproduction
/c/new./projects./api/messages/:idrequest goes out.Root cause
When you navigate away from conversation
X,clearMessagesCache(X)sets[QueryKeys.messages, X]to[]— a defined-but-empty value, notundefined.The messages query (
useGetMessagesByConvoId) defaults torefetchOnMount: false. When you later return toXvianavigateToConvofrom a route whereChatRoutewas unmounted (e.g./projects),ChatViewmounts fresh, finds the cached[], and — perrefetchOnMount: false— never refetches. Result: no network request,messagesTreestays empty, andChatViewshowsLoadingSpinnerforever.It only worked when navigating from another
/c/:idbecause the messages observer stayed continuously mounted there, so the query-key change refetched the stale[]. From a non-chat route the observer mounts fresh and that recovery never happens — an observer-lifecycle accident that shouldn't be load-bearing.Fix
navigateToConvo— the single entry point for in-app conversation navigation — now removes the target's messages cache before fetching:With the cache
undefined, a freshly-mountedChatViewperforms an initial fetch regardless ofrefetchOnMount. This is route-agnostic (works from/projects, search, settings, agent detail — anywhereChatRoutewas unmounted) and doesn't touchclearMessagesCache(removing there would force a wasteful refetch of the outgoing conversation right before it unmounts). It also matches existing behavior — the working case already refetches messages on navigation.Notes
/projects→ reopen flow is a good follow-up.