Fix startup chat history recovery for Issue #816#821
Conversation
ashione
changed the title
There was a problem hiding this comment.
Pull request overview
Improves ClawX chat history recovery on cold startup by adding a targeted retry path for the first foreground chat.history load when Gateway isn’t ready yet, while keeping quiet/background refresh behavior unchanged.
Changes:
- Add startup-only
chat.historyretry + timeout override (initial foreground load only), with error classification based on Gateway status and timeout/unavailable signals. - Apply the retry logic both in modular chat history actions and the live
useChatStore.loadHistorypath. - Add unit and Electron E2E regression coverage for startup history retry behavior.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
src/stores/chat/history-startup-retry.ts |
Introduces shared constants + helpers to classify retryable errors, decide retry eligibility, and provide the startup-only timeout override. |
src/stores/chat/history-actions.ts |
Adds retry loop + startup timeout override to the modular loadHistory, and avoids “burning” the startup path on stale applies. |
src/stores/chat.ts |
Adds parallel retry/timeout behavior in the runtime store path and updates the loading safety timer duration. |
tests/unit/chat-history-actions.test.ts |
Adds unit coverage for retry success, retry exhaustion, and “no retry” cases (quiet + non-retryable errors). |
tests/unit/chat-store-history-retry.test.ts |
Adds unit coverage for the runtime store path (timeout override scoping + stale first attempt not burning retry). |
tests/e2e/chat-history-startup-retry.spec.ts |
Adds an Electron E2E regression spec validating history eventually renders after an initial chat.history timeout. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b485486ec5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
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".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9495c9fac7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
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".
| const isInitialForegroundLoad = !quiet && !_foregroundHistoryLoadSeen.has(currentSessionKey); | ||
| const historyTimeoutOverride = getStartupHistoryTimeoutOverride(isInitialForegroundLoad); |
There was a problem hiding this comment.
isInitialForegroundLoad is keyed only by whether this session has ever been foreground-loaded, so a session opened much later in a long-running app still gets startup settings (35_000 RPC timeout and the extended loading safety timeout) even when gateway startup has long passed. Because retry eligibility is separately gated by connectedAt, this can produce the worst of both worlds for late session switches: no retry, but a much longer stall before surfacing failure if chat.history hangs. Please gate the startup timeout path on gateway startup recency as well (not just per-session first foreground load).
Useful? React with 👍 / 👎.
Summary
chat.historyrequest times out during gateway startup readinessuseChatStore.loadHistoryruntime pathRoot Cause
On cold startup, ClawX could request
chat.historybefore Gateway was fully ready to serve history. The first foreground history load failed immediately, which left the chat page blank when there was no in-memory history to preserve.The first attempt at fixing this also stretched timeout behavior into quiet/background refreshes and burned the "first foreground load" marker even on failed or stale loads.
User Impact
Validation
pnpm run typecheckpnpm exec vitest run tests/unit/chat-history-actions.test.ts tests/unit/chat-store-history-retry.test.tsNotes
tests/e2e/chat-history-startup-retry.spec.ts