🐛 Bugfix: Why did the extension's Repos tab and MCP Dashboard show sta...

Date: 2026-03-31
Time: 12:01:30 UTC
Session: gspace1-290.24
Agent: storage
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

Why did the extension's Repos tab and MCP Dashboard show stale 401 errors after signing in with a fresh JWT?

Task: Fix stale data in extension tabs after re-authentication

🎯 Decision Made

Chosen:

Extension host now posts authChanged message after JWT save. Repos and Dashboard components listen and re-fetch with forceRefresh=true.

Options Considered:

1. Post authChanged event + component listeners (chosen)
2. Have sendInitialState() force-clear all webview caches
3. Add a global auth state in the Lit state store that triggers re-renders

💭 Reasoning

Root cause: Both repositories-view and dashboard-view only fetched data in connectedCallback() (on mount). After signing in, the components were already mounted. handleSaveAuth() called sendInitialState() which re-fetched MCP stats/decisions/agents on the extension host side, but the webview API layer had a cache gate (shouldFetch()) that blocked re-delivery because it thought data was recently fetched. The stale 401 error state persisted until the user manually clicked Refresh. Fix: extension host posts { type: 'authChanged' } after saving JWT. Components listen via onMessage() and call their fetch functions with forceRefresh=true, bypassing the cache gate. This is the correct reactive pattern — components should respond to auth state changes, not rely solely on mount-time fetches.

📁 Files Involved

• apps/vitto-vscode-extension/src/panels/main-panel.ts
• apps/vitto-vscode-extension/src/panels/webview/components/repositories/repositories-view.ts
• apps/vitto-vscode-extension/src/panels/webview/components/dashboard/dashboard-view.ts

🔗 Related

• Decision ID: dev_1774958486841_zb9ztl9
• Session: 290
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation