fix(frontend): stop the session list claiming you have no sessions - #6430
Conversation
The list keeps a previous query's rows on screen while a new key resolves (placeholderData: keepPreviousData), which is right for a pin toggle and stops the skeleton flashing. The view could not tell those rows from a settled answer, so it rendered the empty state over an unsettled query: on a project with 43 sessions the page said 'No sessions yet. Start a conversation with an agent and it will show up here.', with no error and no spinner anywhere on screen. That reads as data loss. useSessionsList now reports isPlaceholder. The empty state waits for a settled query, and the rows dim while they are a previous query's. Scope, honestly: the empty state was observed while the list query was stalled by connection exhaustion (F4 in the QA notes), and I have not reproduced that scenario against this change, so treat the guard as principled rather than verified. It is correct on its own terms — 'you have no sessions' is a claim about the account and must not be made about an unsettled query.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Team Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2 participants
Context
The session list could render "No sessions yet. Start a conversation…" to someone with 43 sessions.
placeholderData: keepPreviousDatakeeps the old rows on screen while a new query key resolves. That is right for a pin toggle, where the rows are the same and only their grouping is being rechecked. It is wrong for a search, where the rows genuinely do not match what was typed. The view could not tell the two apart, so it presented one query's results as the answer to another — and when the previous result happened to be empty, it stated as fact that the account had no sessions.Typing in the search box mints a query per keystroke, so this was reachable by normal use.
Changes
useSessionsListnow exposesisPlaceholder(fromisPlaceholderDataon either query), and the view uses it for two things:aria-busy. Dimmed rather than replaced with a skeleton: the rows are still real, they are just not the answer yet, and swapping them out is exactly the flashkeepPreviousDataexists to avoid.Tests
tsc --noEmitand eslint clean.Not exercised in a browser. The reasoning is from the query state, so it is worth confirming by hand.
What to QA