Summary
After clicking Accept on a Get Solution fix, the partial re-analysis completes but the issue count in the Analysis View never changes. The webview continues to show the original violation count indefinitely.
Reproduction
- Open the
gotest repo (Go, autoscaling/v2beta1 → v2 migration)
- Run full analysis → 3 issues detected
- Get Solution for the autoscaling issue → Accept the fix
- Observe the Analysis View — Total Issues stays at 3 even though:
handleFileResponse wrote the fixed main.go to disk ✅notifyFileChanges was called to invalidate the provider cache ✅runPartialAnalysis was called with [main.go] ✅- The analyzer ran with
included_paths=[main.go], reset_cache=false
Evidence from CI
Root Cause Investigation
Traced the full chain from Accept → webview update:
Accept clicked
→ handleFileResponse()
→ updateExistingFile(): writes fixed file via workspace.fs.writeFile ✅
→ analyzerClient.notifyFileChanges(): sends analysis_engine.NotifyFileChanges RPC ✅
→ runPartialAnalysis(state, [uri]):
→ analyzerClient.runAnalysis([uri]):
→ RPC: analysis_engine.Analyze({ included_paths: ["/path/main.go"], reset_cache: false })
→ kai-analyzer-rpc:
→ runs rules SCOPED to main.go
→ updateCache(): invalidateCachePerFile(paths) + addRulesetsToCache(new)
→ response = createRulesetsFromCache() (full merged set)
→ loadRuleSets(rulesets): updates webview state via ANALYSIS_STATE_UPDATE
Hypothesis: Cache key mismatch in kai-analyzer-rpc
invalidateCachePerFile(paths) deletes cache entries by path string. The cache keys come from incident.URI.Filename() (set by the go-external-provider). The delete keys come from the extension normalizeFilePath(uri.fsPath). If these do not match after normalizePath() in the Go cache, old entries persist and the merged result still contains all original violations.
Alternative hypothesis: Go provider AST cache not invalidated
The go.referenced rules use the go-external-provider AST. Even though NotifyFileChanges is sent, the provider may not re-parse the file from disk before the scoped Analyze call. The old AST would still match autoscalingv2beta1 patterns.
Expected Behavior
After Accept → partial re-analysis, the issue count should drop to reflect the applied fix. For the gotest autoscaling fix, it should go from 3 → 1 (the remaining client-go dependency issue in go.mod).
Workaround
Running a full analysis (reset_cache=true) after Accept correctly picks up the changes. But this defeats the purpose of the partial analysis optimization.
Debug Logging Added
PR #1327 now includes diagnostic logging that will capture:
- Issue count immediately after Accept
- Issue count every 15s during verification polling
- Screenshots at each poll interval
This will confirm whether the count ever changes and help narrow down the root cause.
Related
Summary
After clicking Accept on a Get Solution fix, the partial re-analysis completes but the issue count in the Analysis View never changes. The webview continues to show the original violation count indefinitely.
Reproduction
gotestrepo (Go, autoscaling/v2beta1 → v2 migration)handleFileResponsewrote the fixedmain.goto disk ✅notifyFileChangeswas called to invalidate the provider cache ✅runPartialAnalysiswas called with[main.go]✅included_paths=[main.go],reset_cache=falseEvidence from CI
getIssuesCount()every 15 seconds for 10 full minutes and the count never dropped from 3.Root Cause Investigation
Traced the full chain from Accept → webview update:
Hypothesis: Cache key mismatch in
kai-analyzer-rpcinvalidateCachePerFile(paths)deletes cache entries by path string. The cache keys come fromincident.URI.Filename()(set by the go-external-provider). The delete keys come from the extensionnormalizeFilePath(uri.fsPath). If these do not match afternormalizePath()in the Go cache, old entries persist and the merged result still contains all original violations.Alternative hypothesis: Go provider AST cache not invalidated
The
go.referencedrules use the go-external-provider AST. Even thoughNotifyFileChangesis sent, the provider may not re-parse the file from disk before the scopedAnalyzecall. The old AST would still matchautoscalingv2beta1patterns.Expected Behavior
After Accept → partial re-analysis, the issue count should drop to reflect the applied fix. For the gotest autoscaling fix, it should go from 3 → 1 (the remaining
client-godependency issue ingo.mod).Workaround
Running a full analysis (
reset_cache=true) after Accept correctly picks up the changes. But this defeats the purpose of the partial analysis optimization.Debug Logging Added
PR #1327 now includes diagnostic logging that will capture:
This will confirm whether the count ever changes and help narrow down the root cause.
Related