fix(app): restore local-only conversation from the local server

[Lukas (L4XB)]

Closes #2665.

What was wrong

Since #2542 the local server owns chat history for signed-in users too, and the side panel history always lists those local conversations first. Opening one still went through the cloud query only, the path from before #2542: for a conversation without a cloud record the query resolved to nothing, the conversationId param was cleared and the panel snapped back to its previous view. Cloud-backed conversations kept working, which is exactly the split reported in #2665 (local-only fails, account-backed opens).

#2625 added the local restore for the new tab and for logged-out users (restoreLocally), but the signed-in side panel never reached it.

Change

In the side panel restore effect, when the cloud has no record of the requested conversation, fall through to the same local server restore that logged-out and new-tab users already use (fetchServerConversation via restoreServerConversation). A conversation that does exist in the cloud is restored from there as before, so nothing changes for account-backed history. On a real miss the local path settles the UI the same way the cloud miss did (param cleared, no error banner in the side panel).

Validation

• bun run scripts/run-bun-test.ts --cwd=apps/app ./apps/app: 433 pass, 0 fail across 61 files.
• bunx wxt prepare && tsc --noEmit in apps/app: clean (GraphQL types generated from schema/schema.graphql).
• bunx @biomejs/biome check on the changed file: clean.

Not done here: a browser check against a running local server. The change is confined to the branch that already runs for logged-out users, so the manual check that would help most is a signed-in user opening a local-only conversation from the side panel history.

[github-actions]

All contributors have signed the CLA. Thank you!
_{Posted by the CLA Assistant Lite bot.}

[Lukas (L4XB)]

I have read the CLA Document and I hereby sign the CLA

[Dani Akash (DaniAkash)]

Greptile (@greptileai)

[greptile-apps]

Confidence Score: 4/5

The change appears safe to merge, with a non-blocking gap in regression coverage for the signed-in cloud-miss fallback.

Summary

• Preserves cloud-first restoration for account-backed conversations.
• Reuses the existing local restoration and settlement lifecycle for local-only conversations.
• Lacks focused regression coverage for the newly connected cloud-to-local path.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Conversation ID requested] --> B{Signed-in side panel?}
  B -->|No| E[Restore from local server]
  B -->|Yes| C[Query legacy cloud history]
  C -->|Record found| D[Restore cloud messages]
  C -->|No record| E
  E -->|Record found| F[Restore local messages]
  E -->|Missing or error| G[Settle restoration]
  D --> H[Clear side-panel route parameter]
  F --> H
  G --> H

Loading

_{Reviews (1) · Last reviewed commit: "fix(app): restore a signed-in user's loc..."}

[Lukas (L4XB)]

Thanks for the re-run. Greptile came back 4/5 with one substantive item, and I think it is right: there is no focused regression test for the path this PR actually adds — signed-in, cloud has no record, fall through to the local server restore.

That gap is real rather than cosmetic. chat-session.hooks.ts has no test file of its own; the nearest coverage is chat-session-restore.test.ts, which exercises chat-session-restore.ts rather than the side-panel effect that chooses between cloud and local. So the branch I changed is the one part of the flow nothing asserts, and a future refactor could drop the fallback without turning anything red.

I'd like to close it. What I'd add is a cell that drives the effect with a signed-in session and a conversation the cloud query resolves to nothing for, and asserts the local restore is called and the conversationId param is cleared once — plus the control, that a cloud-backed conversation still restores from the cloud and never reaches the local path.

Two questions before I write it:

1. Do you want it in this PR, or would you rather merge the fix and take the test separately? Greptile called it non-blocking and I don't want to hold the fix behind it if the regression is biting people.
2. Where would you prefer it — a new chat-session.hooks.test.ts, or folded into chat-session-restore.test.ts next to the existing restore coverage?

On the current state: bun run scripts/run-bun-test.ts --cwd=apps/app ./apps/app is 433 pass / 0 fail at cceb386, and tsc --noEmit and Biome are clean on the changed file. The one thing still not done is a browser check against a running local server — a signed-in user opening a local-only conversation from side-panel history. If that is something you can hit quickly, it is the check that would most directly confirm #2665 is gone.

[Dani Akash (DaniAkash)]

Lukas (@L4XB) we can merge this PR, i'll handle the test coverage separately on a new PR