[Bug]: Azure DevOps source control shows "not available" on Windows because the 5s CLI probe times out on slow `az --version` (misclassified as missing)

[eddy-curly]

Before submitting

• I searched existing issues and did not find a duplicate. (Closest is pingdotgg/t3code#2576, a different root cause — see "Relationship to other issues".)
• I included enough detail to reproduce or investigate the problem.

Area

apps/server (source-control discovery). Surfaces in the desktop app's Settings → Source Control Providers UI.

Summary

On Windows, the Azure DevOps connector reports "not available" and shows the install az hint even when the Azure CLI is installed, on PATH, and authenticated. The real cause is not a missing install — it's that the discovery probe runs az --version under a hard-coded 5 s timeout, and az --version on Windows routinely takes 6–8 s (Python startup + the "updates available" check). The probe times out, and the timeout is misclassified as status: "missing", which renders the install hint and skips the (fast, ~1 s) auth check.

This is the next Windows failure mode after pingdotgg/t3code#2576: once az.cmd spawn resolution was fixed, az actually runs — and now it runs too slowly for the 5 s probe budget.

Steps to reproduce

1. On Windows, install Azure CLI (az 2.87.0) + the azure-devops extension (1.0.6), on the machine PATH.
2. az login and confirm auth: az account show --query user.name -o tsv returns your user (~1 s).
3. Confirm az --version works but is slow — on an affected machine it takes ~6–8 s (Azure CLI prints "N updates available" on --version).
4. Open T3 Code → Settings → Source Control Providers → Azure DevOps.
5. The connector shows "not available" with the "Install the Azure command-line tools (az) …" hint, even though az is installed and authenticated.

Measured on the reporting machine: az --version = 7,286 / 6,232 / 5,872 ms across runs; az account show … = ~1.1 s. Server logs show the source-control.discovery.probe operations returning Failure at 5,815 / 7,389 / 7,831 / 5,817 ms — i.e. interrupted at the 5 s ceiling (the >5 s tail is the time to tear down the az.cmd → python process tree on Windows).

Expected behavior

• A CLI that is installed and authenticated but slow to answer --version should be detected as present, not reported as missing.
• A probe timeout must be distinguished from not installed (ENOENT). Only a genuine spawn failure should render the "install az" hint.
• The fast auth check (az account show) should still run when the version probe is merely slow.

Actual behavior

The probe times out at 5 s, the timeout is collapsed into status: "missing", the install hint is shown, the auth check is skipped, and a misleading "Hosting integration command was not found on the server PATH." detail is emitted — even though az is on PATH and works.

Root cause (code references, at main @ 18fa89c4a)

Line numbers are for the TypeScript source (the shipped dist/bin.mjs is the bundled form of the same logic).

1. Discovery spec — apps/server/src/sourceControl/AzureDevOpsSourceControlProvider.ts:41-51
executable: "az", versionArgs: ["--version"], authArgs: ["account","show","--query","user.name","-o","tsv"].

2. Hard-coded 5 s probe timeout + catch-all → "missing" — apps/server/src/sourceControl/SourceControlProviderDiscovery.ts:159-201
probeCli passes timeoutMs: 5_000 (line 170), and its Effect.catch((cause) => …) (lines 189-199) maps every failure — timeout, spawn error, crash — to status: "missing". Note this is a 6× under-cut of the module's own DEFAULT_TIMEOUT_MS = 30_000 (apps/server/src/vcs/VcsProcess.ts:49).

3. Short-circuit skips the auth check — apps/server/src/sourceControl/SourceControlProviderDiscovery.ts:232-238
   When status !== "available", probeSourceControlProvider returns early with unknownAuth("Hosting integration command was not found on the server PATH.") and never runs authArgs (az account show).

4. The information to fix this already exists. apps/server/src/vcs/VcsProcess.ts:112 sets timeoutBehavior: "error", and the mapper at VcsProcess.ts:115-140 produces distinct typed errors — VcsProcessTimeoutError for a timeout vs VcsProcessSpawnError for ENOENT (both asserted in VcsProcess.test.ts). probeCli's untyped catch simply discards that distinction.

Decisive signal: a genuinely missing az fails as VcsProcessSpawnError in milliseconds; the observed failures at 5.8–7.8 s are the timeout signature, not absence. No reinstall changes a >5 s answer to --version.

Proposed fix (small, focused)

1. Stop hard-coding timeoutMs: 5_000 in probeCli — inherit the 30 s default, or raise to ~15–30 s (optionally configurable).
2. In probeCli's catch, branch on the cause tag: only VcsProcessSpawnError → status: "missing" (install hint). A VcsProcessTimeoutError should be a distinct "present but slow / probe timed out" state that preserves the real detail and still attempts the fast auth command.
3. Optional: use the fast az account show (the existing authArgs) as the presence signal instead of az --version, since --version triggers Azure CLI's update-availability check, which is the slow part.

I'd be happy to open a PR for (1)+(2) with a test mirroring the existing VcsProcessTimeoutError coverage, if you're open to it.

Impact

Major degradation or frequent failure — the Azure DevOps connector is effectively unusable on any Windows host where az --version exceeds 5 s (common, given Azure CLI is Python-based and runs an update check). Same practical severity as pingdotgg/t3code#2576.

Version or commit

main @ 18fa89c

Environment

Windows 11 Pro 10.0.26200; Azure CLI az 2.87.0 + azure-devops extension 1.0.6 (at …\CLI2\wbin\az.cmd), authenticated (org urbanlighthouse); Node v24.15.0 / Bun 1.3.13.

Logs or stack traces

# t3code server logs (post-restart, confirmed new PID):
source-control.discovery.probe az --version Failure 5815ms
source-control.discovery.probe az --version Failure 7389ms
source-control.discovery.probe az --version Failure 7831ms
source-control.discovery.probe az --version Failure 5817ms

# Direct timings on the same machine:
az --version ~6232-7286 ms
az account show --query user.name -o tsv ~1100 ms

Relationship to other issues

• pingdotgg/t3code#2576 (closed/COMPLETED) — predecessor: VcsProcessSpawnError because Windows az is az.cmd and spawn couldn't resolve it. Different root cause (fails instantly at the spawn boundary). Its fix is what lets az now run long enough to hit this timeout.
• pingdotgg/t3code#2537 (open) — cosmetic cmd.exe/conhost flashes from the same provider-probe / VCS-process-kill paths. Different symptom, same subsystem.
• pingdotgg/t3code#3525 (open) — a separate hard-coded 5 s timeout causing problems (background git fetch), suggesting the 5 s budget is a recurring foot-gun worth revisiting broadly.

Workaround

None reliable from the user side — the CLI is already installed and authenticated. Restarting/reinstalling az does not help because the probe keeps timing out.