Skip to content

fix(#689): provider cache reset after settings import#726

Open
JunyongParkDev wants to merge 1 commit into
Zoo-Code-Org:mainfrom
JunyongParkDev:fix/settings-provider-import-cache
Open

fix(#689): provider cache reset after settings import#726
JunyongParkDev wants to merge 1 commit into
Zoo-Code-Org:mainfrom
JunyongParkDev:fix/settings-provider-import-cache

Conversation

@JunyongParkDev

@JunyongParkDev JunyongParkDev commented Jun 26, 2026

Copy link
Copy Markdown

Related GitHub Issue

Closes: #689

Description

SettingsView uses a local cachedState buffer so settings edits do not write through to live extension state before Save. After importing settings, the cache-busting effect could run multiple times for the same settingsImportedAt value whenever extensionState changed identity.

That could overwrite an in-progress provider edit with the previously saved provider, making the UI briefly switch and then revert.

This change tracks the handled settingsImportedAt value and resets cachedState only once per import event. It also adds a regression test covering the imported-settings flow where Baseten is saved with an API key, the same import timestamp replays, and a later DeepSeek provider edit is preserved and saved.

Test Procedure

  • Ran the focused webview regression test: - all 3 tests passed.

    pnpm --dir webview-ui exec vitest run src/components/settings/__tests__/SettingsView.change-detection.spec.tsx
    
  • Verified the new regression coverage for the imported-settings flow:

    1. Start with settingsImportedAt set.
    2. Change Provider to Baseten.
    3. Enter a Baseten API key.
    4. Save the settings.
    5. Change Provider to DeepSeek.
    6. Replay the same imported extension state timestamp.
    7. Confirm the Provider remains DeepSeek and Save posts apiProvider: "deepseek".
  • This verifies that SettingsView only busts cachedState once per settingsImportedAt value, so a replayed imported state does not overwrite an in-progress Provider edit.

Pre-Submission Checklist

  • Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
  • Scope: My changes are focused on the linked issue (one major feature/fix per PR).
  • Self-Review: I have performed a thorough self-review of my code.
  • Testing: New and/or updated tests have been added to cover my changes (if applicable).
  • Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
  • Contribution Guidelines: I have read and agree to the [Contributor Guidelines](/CONTRIBUTING.md).

Screenshots / Videos

Documentation Updates

Additional Notes

Get in Touch

Summary by CodeRabbit

  • Bug Fixes

    • Improved settings import handling so imported settings are processed only once, preventing repeated cache refreshes and unintended change-detection resets.
    • Fixed persistence of provider-related settings when the same import timestamp is replayed, ensuring provider edits remain correct after saving and reloading.
  • Tests

    • Strengthened automated coverage for settings change detection and save behavior across provider switches and imported settings replay.

@coderabbitai

coderabbitai Bot commented Jun 26, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

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: 7075b67d-5c40-47de-831d-e28b60274553

📥 Commits

Reviewing files that changed from the base of the PR and between f8ac8ef and 26dea4e.

📒 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/tests/SettingsView.change-detection.spec.tsx
  • webview-ui/src/components/settings/SettingsView.tsx

📝 Walkthrough

Walkthrough

SettingsView now handles each settingsImportedAt value once before refreshing cached settings and clearing change detection. The change-detection spec updates its VS Code mocks, renders provider controls, and adds a regression test for provider changes after imported settings.

Changes

Imported settings replay handling

Layer / File(s) Summary
Guard imported state replay
webview-ui/src/components/settings/SettingsView.tsx
SettingsView stores the last handled settingsImportedAt value, then refreshes cachedState and resets isChangeDetected only for a new import timestamp.
Provider regression test
webview-ui/src/components/settings/__tests__/SettingsView.change-detection.spec.tsx
The spec shares a postMessage mock, renders interactive ApiOptions controls, and adds a regression test that saves provider changes after an import and checks the emitted configuration payload.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested reviewers

  • taltas
  • JamesRobert20
  • hannesrudolph

Poem

A bunny hopped through cache and time,
One import stamp, one truth in rhyme.
Baseten, DeepSeek—save and see,
the settings stayed put, hop-happily.
🐰

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly names the main fix: preventing provider cache resets after settings import.
Description check ✅ Passed The PR includes the required issue link, implementation summary, test procedure, and completed checklist, with only optional sections left blank.
Linked Issues check ✅ Passed The code prevents repeated cache resets after the same import timestamp and adds a regression test for the provider reversion bug in #689.
Out of Scope Changes check ✅ Passed The changes stay focused on the imported-settings provider cache bug and its test coverage, with no unrelated additions.
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 due to a network error.


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.

SettingsView keeps a local cachedState buffer so settings edits do not write through to the live extension state before Save. After importing settings, the import timestamp was used to bust that cache, but the effect could run again for the same import timestamp whenever extensionState changed identity.

That allowed a later live state update to overwrite an in-progress provider edit with the previously saved provider, causing the provider UI to briefly switch and then revert.

Track the handled settingsImportedAt value and only reset cachedState once per import event.

Add a regression test for the imported-settings flow where Baseten is saved with an API key, the same import timestamp is replayed, and a subsequent DeepSeek provider edit is preserved and saved.
@JunyongParkDev JunyongParkDev force-pushed the fix/settings-provider-import-cache branch from f8ac8ef to 26dea4e Compare June 26, 2026 07:33
@codecov

codecov Bot commented Jun 29, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] API Provider can revert to previous Provider after importing settings

1 participant