fix(issue-6): invalidate stale scan cache on resource edits in editor

The Resource Editor webview cached Scan Code results in an in-memory JS
variable that was never cleared while the editor stayed open. Adding a
previously-missing key (or Refresh) left the stale snapshot in place, so
Scan Code kept reporting the key missing until the tab was closed/reopened.

loadResources() now clears scanResultsCache so the next Scan Code re-queries
the backend (whose cache is already invalidated on mutations). Extracted the
cache-lifecycle rules into scanCacheState.ts (mirrored by the inline webview
JS) with regression tests.

Author: nickprotop

vscode-extension/src/test/unit/scanCacheState.test.ts

@@ -0,0 +1,60 @@
+import { expect } from 'chai';
+import {
+  shouldInvalidateScanCache,
+  resolveScanAction,
+  ResourceEditorEvent
+} from '../../views/scanCacheState';
+
+/**
+ * Regression tests for the "Scan Code results become stale after editing keys"
+ * bug (issue #6 follow-up).
+ *
+ * Repro from the report: scan reports a missing key -> add it via the editor ->
+ * scan again still reports it missing; Refresh doesn't help; only closing and
+ * reopening the editor does. Root cause: the webview's in-memory scanResultsCache
+ * was never cleared while the editor stayed open, so "Scan Code" kept short-
+ * circuiting to the snapshot taken when the editor first opened.
+ */
+describe('scan results cache staleness (issue #6 follow-up)', () => {
+  it('invalidates the scan cache after adding a key', () => {
+    expect(shouldInvalidateScanCache('addSuccess')).to.equal(true);
+  });
+
+  it('invalidates the scan cache after updating a key', () => {
+    expect(shouldInvalidateScanCache('updateSuccess')).to.equal(true);
+  });
+
+  it('invalidates the scan cache after deleting a key', () => {
+    expect(shouldInvalidateScanCache('deleteSuccess')).to.equal(true);
+  });
+
+  it('invalidates the scan cache on an explicit Refresh', () => {
+    // The reporter noted Refresh alone did not resolve the stale scan.
+    expect(shouldInvalidateScanCache('refresh')).to.equal(true);
+  });
+
+  it('re-queries the backend once the cache is cleared', () => {
+    expect(resolveScanAction(null)).to.equal('requery');
+  });
+
+  it('still serves the cache while it is populated (fast re-open)', () => {
+    expect(resolveScanAction({ missing: [], unused: [], references: [] })).to.equal('use-cache');
+  });
+
+  it('end-to-end: add-then-rescan re-queries instead of reusing the stale snapshot', () => {
+    // Simulate the webview state machine.
+    let cache: unknown | null = { missing: ['Processing_Description_Label'], references: [] };
+
+    // First scan uses the snapshot.
+    expect(resolveScanAction(cache)).to.equal('use-cache');
+
+    // User adds the missing key -> loadResources() runs -> cache cleared.
+    const event: ResourceEditorEvent = 'addSuccess';
+    if (shouldInvalidateScanCache(event)) {
+      cache = null;
+    }
+
+    // Next "Scan Code" must hit the backend, which no longer reports it missing.
+    expect(resolveScanAction(cache)).to.equal('requery');
+  });
+});

vscode-extension/src/views/resourceEditor.ts

@@ -1147,6 +1147,16 @@ export class ResourceEditorPanel {
 
         function loadResources() {
             setStatus('Loading...');
+            // Drop the cached scan results so the next "Scan Code" re-queries the
+            // backend. loadResources() runs on every add/update/delete and on the
+            // Refresh button, so without this the modal kept showing the scan
+            // snapshot taken when the editor first opened — a key added in the
+            // editor was still reported missing until the tab was closed/reopened.
+            // The backend cache is already invalidated on mutations, so a fresh
+            // re-query returns correct results. If the extension re-sends valid
+            // cached scan results right after (handleLoadResources), that simply
+            // repopulates with the backend's current state, which is what we want.
+            scanResultsCache = null;
             vscode.postMessage({ command: 'loadResources' });
         }
 

vscode-extension/src/views/scanCacheState.ts

@@ -0,0 +1,55 @@
+/**
+ * Scan-results cache lifecycle for the Resource Editor webview.
+ *
+ * The webview keeps the last "Scan Code" result in a JS variable so re-opening the
+ * modal is instant. The bug (issue #6 follow-up) was that this cache was never
+ * cleared while the editor stayed open: adding a previously-missing key in the
+ * editor left the stale snapshot in place, so "Scan Code" (and even the Refresh
+ * button) kept reporting the key as missing until the tab was closed and reopened.
+ *
+ * The webview's HTML/JS is built as a string and cannot import this module, so these
+ * are the canonical, unit-tested rules the inline logic MUST mirror:
+ *
+ *  - Any resource mutation (add/update/delete) and the explicit Refresh both funnel
+ *    through loadResources(), which clears the cache. The backend cache is already
+ *    invalidated on mutations, so the next scan re-queries fresh.
+ *  - "Scan Code" only short-circuits to the in-memory cache when it is still present;
+ *    once cleared it posts a real `scanCode` message to the extension.
+ */
+
+export type ScanResultsCache = unknown | null;
+
+/**
+ * Events that occur while the editor is open and that affect whether the cached scan
+ * snapshot is still trustworthy.
+ */
+export type ResourceEditorEvent =
+  | 'refresh' // user clicked the Refresh button
+  | 'addSuccess' // a key was added
+  | 'updateSuccess' // a key value was updated
+  | 'deleteSuccess'; // a key was deleted
+
+/**
+ * Whether the cached scan snapshot must be invalidated in response to an event.
+ * Every event that reloads the resource grid also invalidates the scan cache, because
+ * the set of keys (and therefore which keys are missing/unused) may have changed.
+ */
+export function shouldInvalidateScanCache(event: ResourceEditorEvent): boolean {
+  switch (event) {
+    case 'refresh':
+    case 'addSuccess':
+    case 'updateSuccess':
+    case 'deleteSuccess':
+      return true;
+    default:
+      return false;
+  }
+}
+
+/**
+ * Decide what "Scan Code" should do given the current cache. When the cache has been
+ * cleared (null), it must re-query the backend rather than re-displaying stale data.
+ */
+export function resolveScanAction(cache: ScanResultsCache): 'use-cache' | 'requery' {
+  return cache ? 'use-cache' : 'requery';
+}