refactor: modularize validation (non-stacked)

[oyi77]

Replaces #3797 as an independent, non-stacked PR branched from release/v3.8.27.

Extracts 4.2K-line validation.ts into modular structure.

Supersedes: #3797

[gemini-code-assist]

Code Review

This pull request modularizes the provider validation logic by splitting it into separate files under src/lib/providers/validation/ (including core.ts, enterprise.ts, search.ts, specialty.ts, standard.ts, utils.ts, and web.ts) and re-exporting them via index.ts. The review feedback highlights three key issues: the isLocal flag is not passed to specialty validators in core.ts (which can break local/private network deployments), a try-catch block in validateAzureOpenAIProvider prematurely returns on error and prevents probe fallbacks, and crypto is used globally in web.ts without an explicit import, potentially causing compatibility issues in older Node.js environments.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The isLocal flag is determined from the provider at the beginning of validateProviderApiKey but is never passed to any of the SPECIALTY_VALIDATORS. Consequently, specialty and enterprise validators (such as Databricks, Azure OpenAI, Snowflake, etc.) do not receive isLocal and default to false when calling validationRead or validationWrite. This causes local or private network deployments of these services to fail validation because the outbound URL guard blocks private IP ranges and proxy fallback is incorrectly attempted.

Suggested change

	if (SPECIALTY_VALIDATORS[provider]) {
	try {
	return await SPECIALTY_VALIDATORS[provider]({ apiKey, providerSpecificData });
	} catch (error: any) {
	return toValidationErrorResult(error);
	}
	}
	if (SPECIALTY_VALIDATORS[provider]) {
	try {
	return await SPECIALTY_VALIDATORS[provider]({ apiKey, providerSpecificData, isLocal });
	} catch (error: any) {
	return toValidationErrorResult(error);
	}
	}

[gemini-code-assist]

In validateAzureOpenAIProvider, the loop iterates over two probe URLs (deployments and models). However, the try-catch block inside the loop immediately returns toValidationErrorResult(error) if validationRead throws an error (e.g., due to a network timeout or endpoint-specific restriction). This prevents the loop from trying the second probe URL or falling through to the chat probe, defeating the fallback design.

  for (const probeUrl of [
    `${baseUrl}/openai/deployments?api-version=${encodedVersion}`,
    `${baseUrl}/openai/models?api-version=${encodedVersion}`,
  ]) {
    try {
      const response = await validationRead(probeUrl, { method: "GET", headers });
      if (response.ok) {
        return { valid: true, error: null, method: "azure_probe" };
      }
      if (response.status === 401 || response.status === 403) {
        return { valid: false, error: "Invalid API key" };
      }
      if (response.status === 400 || response.status === 404 || response.status === 405) {
        continue;
      }
      if (response.status === 429) {
        return {
          valid: true,
          error: null,
          method: "azure_probe",
          warning: "Rate limited, but credentials are valid",
        };
      }
      if (response.status >= 500) {
        return { valid: false, error: `Provider unavailable (${response.status})` };
      }
    } catch (error) {
      // Ignore error to allow fallback to the next probe URL or chat probe
    }
  }

[gemini-code-assist]

The file uses crypto.randomUUID() and crypto.getRandomValues() but only imports randomUUID from node:crypto. It does not import the crypto default export. While modern Node.js environments (v19+) expose crypto globally, older LTS versions (like Node 18) do not, which will cause a ReferenceError: crypto is not defined at runtime. It is safer and more backward-compatible to import crypto explicitly.

import crypto, { randomUUID } from "node:crypto";

[diegosouzapw]

Thanks @oyi77 — blockers for the validation modularization:

1. Rebase onto current release/v3.8.27: conflicts with merged fix(qwen-web): cookie validation false-positive - check response body for user object #3958 (qwen-web validator now inspects the 200 body for a user object) on validation.ts.
2. Sub-split the oversized modules: validation/web.ts (1193) and validation/specialty.ts (867) exceed the 800-line new-file cap (that's why Fast Quality Gates is red). Split them into cohesive sub-modules.
3. Verify lossless (siblings dropped content — refactor: modularize provider registry (non-stacked) #3993 dropped 2 providers, refactor: modularize usage (non-stacked) #3989 dropped the vertex usage fetcher): diff every validator export + the per-provider validator dispatch monolith-vs-modules. A dropped validator makes a provider show 'not supported'.

[diegosouzapw]

Thanks for all the modularization work here, @oyi77 🙏. We've decided to hold the per-module "non-stacked" refactors and run the decomposition as one coordinated pass after the in-flight quality-gate work lands, instead of merging them piecemeal. Reason: on the two we did merge (#3993, #3988) we caught logic being dropped during the move — and the gates (provider-consistency / typecheck) don't detect internal-logic loss — so each of these needs a full lossless audit, which isn't tractable across many overlapping PRs against a moving release branch right now. The coordinated modularization is tracked in #3501 / #3594; we'd genuinely value your input on that plan once it's up. Closing for now — purely sequencing, not a reflection on the effort.