Fix Windows clean-install managed runtime smoke for ktx sl query

[andreybavt]

Problem

PR #215 fixed the Windows pnpm/package-artifact invocation path enough for the artifact unit tests and clean npm package install to get much further, but the Windows clean-install smoke still fails when the installed CLI first uses the managed Python runtime.

On a fresh Windows Server 2022 environment with Git available, this passed:

• node --test scripts/package-artifacts.test.mjs (18 tests, 0 failures)
• npm tarball build/package/install
• pnpm exec ktx --version
• ktx setup --no-input ...
• ktx wiki ...
• ktx sl ... search

The remaining failure is on the first query that needs the managed runtime:

pnpm exec ktx sl query --connection-id warehouse --measure orders.order_count --format json --yes --project-dir <temp-project>
AssertionError [ERR_ASSERTION]: ktx sl query first managed runtime install failed with code 1

The stderr output only showed the managed Python runtime install starting with uv before the process exited with code 1.

Expected

A clean installed ktx npm package on Windows should be able to install/use the managed Python runtime and complete the ktx sl query smoke.

Suggested Follow-Up

Investigate why the managed runtime install exits 1 on Windows during the clean-install smoke, then add or update Windows coverage so scripts/package-artifacts.mjs check can validate this path end to end.

[andreybavt]

@Aryan1718 would you like to look into it?

[Aryan1718]

Hello @andreybavt , I will look into it and let you know.

[Aryan1718]

Hello @andreybavt ,

What I tested

From the repo root:

node scripts/package-artifacts.mjs check

This completed successfully, including the same first managed-runtime install path that was reported as failing:

$ cmd.exe /d /s /c pnpm exec ktx sl query --connection-id warehouse --measure orders.order_count --format json --yes --project-dir ...

$ cmd.exe /d /s /c pnpm exec ktx admin runtime status --json

ktx managed runtime lazy install verified

I also reran the same flow with a fresh local environment to reduce the chance of reusing an existing runtime or uv cache:

$runRoot = Join-Path $env:TEMP ("ktx-fresh-run-" + [guid]::NewGuid().ToString())
$uvCache = Join-Path $runRoot "uv-cache"
$ktxHome = Join-Path $runRoot "ktx-home"

New-Item -ItemType Directory -Path $uvCache -Force | Out-Null
New-Item -ItemType Directory -Path $ktxHome -Force | Out-Null

$env:UV_CACHE_DIR = $uvCache
$env:HOME = $ktxHome
$env:USERPROFILE = $ktxHome
$env:KTX_RUNTIME_ROOT = Join-Path $ktxHome ".ktx\runtime"

node scripts/package-artifacts.mjs check

That fresh run also completed successfully on my machine.

What I investigated next

Since I could not reproduce the failure with the normal 30_000ms timeout, I tested whether this was a timeout/cold-start issue.

I built the normal package artifacts:

node scripts/package-artifacts.mjs build

Then I created a throwaway packed-package smoke workspace from the generated tarball, modified only the generated temp verify-installed-cli.mjs timeout, and reran the installed-CLI smoke with fresh runtime/cache state.

Timeout hypothesis results

• With the timeout reduced to 5_000ms, the smoke failed too early at ktx setup, so that value was too aggressive to be useful.
• With the timeout reduced to 20_000ms, the smoke failed at the exact reported step:

ktx sl query first managed runtime install failed with code 1

The stderr for that failure showed the managed runtime install starting and finishing:

Installing KTX Python runtime (core) with uv...
KTX Python runtime ready: ...

Current conclusion

Based on local testing, I could not reproduce this with the normal artifact smoke flow, even with a fresh runtime root and fresh uv cache.

However, reducing the allowed timeout in the generated installed-CLI smoke reproduced the same failing step on Windows. That strongly suggests this is likely a timeout/cold-start issue in the clean-install smoke path, rather than a general functional failure of managed runtime installation on Windows.

The first ktx sl query --yes path has to do the initial managed Python runtime install with uv, and that appears to be sensitive to the available time budget on fresh/slower Windows environments.

[Aryan1718]

Hey @andreybavt , do you want me to update this and create a PR so you can test it out?