René's URL Explorer Experiment

Title: Fix flaky query history reveal test via stable TreeItem ids by cklin · Pull Request #4468 · github/vscode-codeql · GitHub

Open Graph Title: Fix flaky query history reveal test via stable TreeItem ids by cklin · Pull Request #4468 · github/vscode-codeql

X Title: Fix flaky query history reveal test via stable TreeItem ids by cklin · Pull Request #4468 · github/vscode-codeql

Description: Summary Fixes a flaky test in query-history-manager.test.ts (the handleRemoveHistoryItem › "should not change the selection" cases), which was failing on CI (e.g. this windows-latest run). Root cause HistoryTreeDataProvider.getTreeItem never set a TreeItem.id. When no id is provided, VS Code identifies tree nodes by their label plus their position in the list (/:). When multiple history items share the same label, that positional identity is ambiguous, so treeView.reveal(item) can resolve to the wrong item or fail outright (Data tree node not found) whenever the list is re-sorted or refreshed. The test overrides the label format to just ${queryName}, so all six mock variant-analysis items render with the identical label a-query-name (javascript). Combined with the randomised sort order (executionStartTime is faker.number.int()), reveal(selected) intermittently selected the wrong item, so getCurrent() no longer equalled selected. Impact Mainly test-only. The production default label format is ${queryName} on ${databaseName} - ${status} ${resultCount} [${startTime}], which includes the start time — so real history labels are effectively unique and users are very unlikely to hit this. The one exception is a user who customises codeQL.queryHistory.format to something non-unique. Because the impact is effectively test-only, no changelog entry is added. Fix Set a stable, unique id on each tree item so reveal resolves deterministically regardless of duplicate labels or sort order. The id must be unique per item. getQueryId alone is not sufficient: a multi-query run (a query suite / multiple .ql files) produces several local-query history entries that are cloned from the same initialInfo and therefore share the same initialInfo.id (see completeQueries in query-history-manager.ts). Since VS Code de-duplicates nodes that share an id — which would break reveal/selection for all but one of the colliding rows — the id for local queries also includes the per-result outputBaseName, which is distinct for each entry (and is persisted, so this also disambiguates already-saved histories). Variant-analysis ids are already unique. Validation tsc --noEmit and eslint pass. Ran the affected test in a loop (retries disabled) on macOS: Before: ~20/40 failures (~50%). After (initial fix and after addressing review feedback): 0 failures across repeated runs.

Open Graph Description: Summary Fixes a flaky test in query-history-manager.test.ts (the handleRemoveHistoryItem › "should not change the selection" cases), which was failing on CI (e.g. this windows-latest run)...

X Description: Summary Fixes a flaky test in query-history-manager.test.ts (the handleRemoveHistoryItem › "should not change the selection" cases), which was failing on CI (e.g. this windows-lat...

Opengraph URL: https://github.com/github/vscode-codeql/pull/4468

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width