fix: reset summary panel on stop-scan [IDE-1035]

[acke]

User description

Summary

• New resetSummaryPanelOnStopScan helper reuses the existing resetSummaryPanelForOrgChange reset path.
• windowWorkDoneProgressCancelHandler invokes it after progress.Cancel, so pressing the stop-scan button now clears the summary back to its initial state instead of leaving stale counts on screen.
• Three unit tests: happy path, nil aggregator, no folders.

Why

When the user pressed stop-scan, the summary panel kept showing the previous scan's counts even though the scan was cancelled. The org-change flow already had a helper to reset the panel to initial state — this PR wires the same helper into the stop-scan LSP handler (window/workDoneProgress/cancel).

Test plan

• TestResetSummaryPanelOnStopScan_CallsInit
• TestResetSummaryPanelOnStopScan_NilAgg_DoesNotPanic
• TestResetSummaryPanelOnStopScan_NoFolders_DoesNotCallInit
• Manual: start a scan, press stop, observe the summary returns to initial / empty.

Jira: IDE-1035
Triage: Buglist

---

PR Type

Bug fix, Tests

---

Description

• Fixes stale summary panel counts after scan stop.

• Introduces helper to reset summary panel state.

• Integrates reset logic into scan cancellation handler.

• Adds unit tests for reset functionality verification.

---

Diagram Walkthrough

flowchart LR
  LSPClient -- "window/workDoneProgress/cancel" --> Server;
  Server -- "windowWorkDoneProgressCancelHandler" --> Server;
  Server -- "resetSummaryPanelOnStopScan" --> Server;
  Server -- "resetSummaryPanelForOrgChange" --> ScanAggregator;
  ScanAggregator -- "Init" --> SummaryPanel;

Loading

File Walkthrough

	Relevant files
Enhancement	configuration.go Add helper to reset summary panel                                                application/server/configuration.go Added resetSummaryPanelOnStopScan function. This new helper retrieves current workspace folder paths and delegates to resetSummaryPanelForOrgChange. Encapsulates the logic for resetting the summary panel to its initial state. +9/-0
Tests	configuration_test.go Add tests for summary panel reset                                                application/server/configuration_test.go Introduced three new unit tests for resetSummaryPanelOnStopScan. Tests cover: happy path calling Init, handling a nil aggregator without panicking, and not calling Init when no folders are present. +39/-0
Bug fix	server.go Integrate summary panel reset into cancel scan handler      application/server/server.go Modified windowWorkDoneProgressCancelHandler to accept configuration.Configuration. The handler now calls resetSummaryPanelOnStopScan after cancelling progress, ensuring the summary panel is cleared. +4/-2

---

[acke]

/describe

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[snyk-pr-review-bot]

PR Description updated to latest commit (65ff59e)

[acke]

/describe

[snyk-pr-review-bot]

PR Description updated to latest commit (89251fb)

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Stale Callback Bug 🟠 [major] The handler registers a reset callback for every folder in the workspace whenever any scan is cancelled. For folders not part of the current scan, these callbacks persist in the DelegatingConcurrentScanner and will be executed at the end of the next scan for those folders. This results in successful scan results being immediately wiped by the stale reset callback. The Tracker should ideally store its associated folder path so the handler can scope the registration to the affected folder only. for _, fp := range workspaceFolderPaths(conf) { sc.RegisterCancelCallback(fp, func() { resetSummaryPanel(scanAgg, []types.FilePath{fp}) }) } Broad Reset Blast Radius 🟡 [minor] In a multi-folder workspace, cancelling a scan for Folder A triggers a summary panel reset for all folders via the registered callbacks. This is overly aggressive as it clears results for other folders that may have finished successfully or are still being scanned independently. Restricting the reset to the folder(s) associated with the cancelled token would improve the user experience. for _, fp := range workspaceFolderPaths(conf) { sc.RegisterCancelCallback(fp, func() { resetSummaryPanel(scanAgg, []types.FilePath{fp}) }) }

📚 Repository Context Analyzed This review considered 40 relevant code sections from 12 files (average relevance: 0.95) internal/progress/progress.go (lines 1-295) domain/scanstates/scan_state_aggregator.go (2 segments, lines 1-200) domain/ide/workspace/folder.go (2 segments, lines 225-467) infrastructure/code/code_tracker.go (lines 1-99) domain/snyk/scanner/test_scanner.go (lines 1-102) domain/scanstates/noop_state_aggregator.go (lines 1-60) application/server/notification.go (lines 1-215) ... and 5 more file(s)

[basti-snyk]

Should fix — cancel resets every folder, not the cancelled one. This loop registers a reset callback for every workspace folder, but params.Token identifies a single per-product tracker belonging to one folder. In a multi-folder workspace, cancelling folder A's scan also registers reset callbacks on folders B, C… Those callbacks are not consumed now (no in-flight scan there) and instead fire on each of those folders' next Scan() completion (scanner.go consumeCancelCallback), wiping valid results the user never asked to clear. Consider mapping the cancelled token back to its owning folder and registering the reset only for that folder.

(Three of the four reviewers independently flagged this as the root cause of a cluster of data-loss bugs.)

— AI review

[basti-snyk]

Should fix — consume is unconditional and unreachable on early returns. Two related issues:

1. consumeCancelCallback(folderPath) fires at the end of every Scan() with no check that this scan was cancelled. A callback registered during a cancel therefore also resets the panel after the folder's next successful scan — turning "reset on cancel" into "reset on next scan completion", wiping valid results.

2. This call sits after the WaitGroups, past several early returns in Scan() (missing FolderConfig, offline, not authenticated, already-cancelled ctx). If the next thing that happens to the folder hits one of those guards, the registered callback is neither fired nor cleared — it lingers and fires against a still-later scan.

Consider draining/clearing the folder's callback in a defer at the top of Scan() (after folderPath is known) so every exit path consumes it exactly once, and gate the reset on whether the scan was actually cancelled.

— AI review

[basti-snyk]

ℹ️ Automated AI review summary — non-blocking; the actionable items are posted as inline comments.

Reviewed origin/main...HEAD with four independent reviewers (semantic analysis, adversarial, security scan, code-review). Strong convergence.

What's solid: The core IDE-1035 race fix is correct and well-tested. Scan-token scoping (IsScanToken) keeps generic CLI download/install cancels from wiping results; the register-before-defer Cancel ordering plus consuming after both WaitGroups guarantees the reset can't race in-flight SetScanDone writes (covered by TestScan_CancelCallback_CalledAfterGoroutinesFinish). The removal of the synchronous racy fallback when the scanner is missing is the right call.

Should fix (data-loss cluster, one root cause): The cancel token carries no folder identity, and the reset is keyed to a future Scan() of each folder. This produces three related defects, all regressions vs. the old handler which never touched the panel — see the two inline comments. Plus a feature gap:

• No in-flight scan at cancel time: if the user stops when the scan has already completed (or no scan is running for the folder), the callback is registered but never consumed, so the panel is never reset — the user-visible intent of stop-scan silently no-ops, and the orphaned callback later corrupts the next scan.

Open question for the author: does the IDE client send one window/workDoneProgress/cancel per scan, or one per product token? progress.Cancel(params.Token) stops only the single product tracker, while the reset waits for all products to finish — so non-cancelled products run to completion and then the panel is wiped. The blast-radius and severity of the above depend on this. Worth confirming against the ticket ACs whether "reset all folders on any stop-scan" is intended or a defect.

Suggestions (non-blocking):

• NewScanTracker (internal/progress/progress.go) inserts the tracker via NewTracker (isScan=false), then re-locks trackersMutex to set isScan=true. Narrow TOCTOU window + a wasted lock. Set the flag in a single locked insertion via a shared private constructor taking the flag.
• The isScan bool on the generic Tracker is a domain (scan-vs-download) classifier bolted onto generic progress plumbing; consider whether the scan/generic distinction belongs where the cancel handler already knows the scanner/aggregator.

Coverage gap: no test exercises the stale/orphaned callback paths — e.g. register a callback for a not-scanning folder, run a fresh successful scan, and assert the panel is not wiped; and drive Scan() through an early-return guard and assert the callback is drained.

Security: no findings introduced. CI is currently red — please confirm failures are unrelated before merge.

— AI review