Integration tests fail locally when desktop Kusto Explorer data is present (import prompt blocks activation)

Problem

npm run test:integration fails for a developer who has desktop Kusto Explorer data on their machine:

1) ScratchPad1 document is open by default:
   AssertionError [ERR_ASSERTION]: ScratchPad1 should be open after activation

46 passing (21s)
1 failing

The cause appears in the same output:

rejected promise not handled within 1 second: Error: DialogService: refused to show dialog in tests.
Contents: Kusto Explorer connections and query set documents found. Would you like to import them?

The extension prompts to import connections from desktop Kusto Explorer during activation. The test DialogService refuses modal dialogs, that rejection goes unhandled, and activation never completes — so ScratchPad1 is never opened and the assertion fails. The failing test is a symptom; the prompt is the cause.

The suite is not hermetic

The failure depends on machine and profile state rather than on the code under test. Evidence gathered by running the same suite in two worktrees on the same machine, both based on the same main:

Neither branch touches activation, connection import, or the scratchpad. The differentiator is the per-worktree .vscode-test/user-data profile: once a profile has recorded that the import prompt was handled, the prompt stops firing and the suite goes green. A fresh profile plus desktop Kusto Explorer data present on the machine reproduces the failure.

This was also independently controlled for by reverting a branch's changed files to its merge-base and re-running: the identical 46/1 failure persisted, confirming it is not caused by the code under test.

CI is unaffected — hosted runners have no desktop Kusto Explorer installation, so the prompt never fires there and Integration Tests (VS Code) passes. That is precisely why this only bites locally, and only for contributors who actually use the desktop product.

Suggested fix

The extension already contributes a setting for exactly this:

msKustoExplorer.connections.suppressKustoExplorerImportPrompt  (boolean, default false)

.vscode-test.mjs currently passes only:

launchArgs: [
  "--disable-updates",
  "--skip-release-notes",
  "--user-data-dir", ".vscode-test/user-data",
],

Seeding that setting to true for the test profile — or otherwise stubbing the desktop-import detection during integration runs — would make the suite independent of whether the developer has desktop Kusto Explorer installed.

Separately, the unhandled promise rejection is worth a look on its own: a refused or dismissed dialog blocking activation is a failure mode that could plausibly affect real users who dismiss the prompt in an unexpected way, not just tests.

Reproduction

1. Have desktop Kusto Explorer connections/query sets present on the machine.
2. Delete src/Client/.vscode-test/user-data so the test profile is fresh.
3. npm run test:integration from src/Client.

Start in src/Client/.vscode-test.mjs and inspect the integration-test launchArgs and test profile setup. Run npm run test:integration with a fresh src/Client/.vscode-test/user-data profile and desktop Kusto Explorer data present; done means the suite no longer shows the import prompt failure and the ScratchPad1 test passes.