fix(webview): sync cachedState on mode changes in SettingsView by easonLiangWorldedtech · Pull Request #925 · Zoo-Code-Org/Zoo-Code

easonLiangWorldedtech · 2026-07-17T14:36:26Z

Problem

In parallel mode, SettingsView shows stale mode and apiConfiguration values because its internal cachedState only updates via useEffect when currentApiConfigName changes, but doesn't refresh when mode changes through handleModeSwitch().

Fix

Add mode to the dependency array of the useEffect that updates cachedState:

Modified Files

webview-ui/src/components/settings/SettingsView.tsx

Changes

Destructure mode from extensionState (line 133)
Add prevMode ref to track previous mode value (line 150)
Update useEffect condition to check both currentApiConfigName and mode (line 226)
Add mode to the dependency array (line 234)

// Before
if (prevApiConfigName.current === currentApiConfigName) {
    return
}

// After
if (prevApiConfigName.current === currentApiConfigName && prevMode.current === mode) {
    return
}

Closes #914

Summary by CodeRabbit

Bug Fixes
- Settings now stay synchronized when the application mode changes.
- Unsaved-change indicators and save-button state now reset correctly after mode-triggered synchronization.
- Improved automated coverage for mode change detection, including scenarios that should not re-sync on re-render without mode changes.

coderabbitai · 2026-07-17T14:38:10Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 1235605a-27c8-4719-99cf-544825937def

📥 Commits

Reviewing files that changed from the base of the PR and between 9d21d45 and 13fe3ad.

📒 Files selected for processing (2)

webview-ui/src/components/settings/SettingsView.tsx
webview-ui/src/components/settings/__tests__/SettingsView.change-detection.spec.tsx

🚧 Files skipped from review as they are similar to previous changes (2)

webview-ui/src/components/settings/SettingsView.tsx
webview-ui/src/components/settings/tests/SettingsView.change-detection.spec.tsx

📝 Walkthrough

Walkthrough

Changes

Settings cache synchronization

Layer / File(s)	Summary
Track mode changes during cache synchronization `webview-ui/src/components/settings/SettingsView.tsx`	`SettingsView` tracks the previous `mode` and re-syncs cached state when either `mode` or `currentApiConfigName` changes, resetting the change-detected flag.
Validate mode synchronization behavior `webview-ui/src/components/settings/__tests__/SettingsView.change-detection.spec.tsx`	Tests add mode-aware mocks, adjusted async timeouts, and coverage for synchronization after mode changes and no synchronization when mode is unchanged.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related issues

[UX] SettingsView shows stale mode/apiConfig in multi-tab mode #914 — Addresses stale cached settings when mode changes.
[UX] Multi-tab mode isolation — follow-up issues from PR #909 #913 — Tracks synchronization of stale SettingsView mode and API configuration state.

Possibly related PRs

Zoo-Code-Org/Zoo-Code#909 — Isolates per-view mode state that this synchronization logic consumes.

Suggested labels: awaiting-review

Suggested reviewers: navedmerchant

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description covers the problem and fix, but it omits key template sections like Test Procedure and the linked-issue checklist.	Add the required Related GitHub Issue and Test Procedure sections, and fill out the template checklists and any relevant review notes.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main fix: syncing cached state when mode changes in SettingsView.
Linked Issues check	✅ Passed	The code updates cachedState on both mode and API config changes and adds tests matching issue `#914`'s acceptance criteria.
Out of Scope Changes check	✅ Passed	The added test mocks and timeout adjustments support the mode-sync fix and do not introduce unrelated scope.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 ESLint

If the error stems from missing dependencies, add them to the package.json file. For unrecoverable errors (e.g., due to private dependencies), disable the tool in the CodeRabbit configuration.

ESLint install failed: dependency version conflict. Check your lock file or package.json.

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.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

codecov · 2026-07-17T14:40:21Z

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

coderabbitai

🧹 Nitpick comments (1)

webview-ui/src/components/settings/SettingsView.tsx (1)
224-234: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Update Vitest coverage for mode synchronization.

As per coding guidelines, please ensure that the local Vitest test (webview-ui/src/components/settings/__tests__/SettingsView.spec.tsx) is updated to cover this new React hook behavior. The test should verify that when the mode changes in extensionState, the component's dirty state is correctly reset and the new mode settings are synchronized to cachedState.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@webview-ui/src/components/settings/SettingsView.tsx` around lines 224 - 234,
The SettingsView tests do not cover the new mode-synchronization behavior in the
effect guarding on prevApiConfigName and prevMode. Update the Vitest cases in
SettingsView.spec.tsx to change extensionState.mode after the component is
dirty, then verify changeDetected resets and cachedState reflects the new mode
settings.
Source: Coding guidelines

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@webview-ui/src/components/settings/SettingsView.tsx`:
- Around line 224-234: The SettingsView tests do not cover the new
mode-synchronization behavior in the effect guarding on prevApiConfigName and
prevMode. Update the Vitest cases in SettingsView.spec.tsx to change
extensionState.mode after the component is dirty, then verify changeDetected
resets and cachedState reflects the new mode settings.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: baa04223-c09f-4573-8b66-24b3973d3b3c

📥 Commits

Reviewing files that changed from the base of the PR and between 367013f and 6372c82.

📒 Files selected for processing (1)

webview-ui/src/components/settings/SettingsView.tsx

coderabbitai

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@webview-ui/src/components/settings/__tests__/SettingsView.change-detection.spec.tsx`:
- Around line 607-640: Update the “does not trigger sync when mode has not
changed” test to create a dirty local provider state before rerendering, while
keeping the mocked extensionState provider as “openai.” Assert that the locally
modified provider value remains after rerender, so an unintended synchronization
would be detected rather than masked by identical values.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

Push a commit to this branch (recommended)
Create a new PR with the fixes

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5414c876-564b-4c0e-88e1-a770dd725d2b

📥 Commits

Reviewing files that changed from the base of the PR and between 6372c82 and 9d21d45.

📒 Files selected for processing (2)

webview-ui/src/components/settings/SettingsView.tsx
webview-ui/src/components/settings/__tests__/SettingsView.change-detection.spec.tsx

🚧 Files skipped from review as they are similar to previous changes (1)

webview-ui/src/components/settings/SettingsView.tsx

easonLiangWorldedtech requested review from JamesRobert20, edelauna, hannesrudolph, navedmerchant and taltas as code owners July 17, 2026 14:36

coderabbitai Bot reviewed Jul 17, 2026

View reviewed changes

easonLiangWorldedtech force-pushed the fix/914-settingsview-stale-mode-apiconfig branch from 6372c82 to 9d21d45 Compare July 17, 2026 15:10

coderabbitai Bot reviewed Jul 17, 2026

View reviewed changes

Comment thread webview-ui/src/components/settings/__tests__/SettingsView.change-detection.spec.tsx

fix(webview): sync cachedState on mode changes in SettingsView

13fe3ad

easonLiangWorldedtech force-pushed the fix/914-settingsview-stale-mode-apiconfig branch from 9d21d45 to 13fe3ad Compare July 17, 2026 15:17

github-actions Bot added the awaiting-review PR changes are ready and waiting for maintainer re-review label Jul 17, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(webview): sync cachedState on mode changes in SettingsView#925

fix(webview): sync cachedState on mode changes in SettingsView#925
easonLiangWorldedtech wants to merge 1 commit into
Zoo-Code-Org:mainfrom
easonLiangWorldedtech:fix/914-settingsview-stale-mode-apiconfig

easonLiangWorldedtech commented Jul 17, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

coderabbitai Bot commented Jul 17, 2026 •

edited

Loading

Walkthrough

Changes

❌ Failed checks (1 warning)

Uh oh!

codecov Bot commented Jul 17, 2026 •

edited

Loading

Uh oh!

coderabbitai Bot left a comment

Uh oh!

coderabbitai Bot left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

easonLiangWorldedtech commented Jul 17, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Fix

Modified Files

Changes

Summary by CodeRabbit

Uh oh!

coderabbitai Bot commented Jul 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

❌ Failed checks (1 warning)

Uh oh!

codecov Bot commented Jul 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

easonLiangWorldedtech commented Jul 17, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Jul 17, 2026 •

edited

Loading

codecov Bot commented Jul 17, 2026 •

edited

Loading