[oyi77]

Summary

This PR addresses another core backend massive file from Issue #3594: src/lib/providers/validation.ts at 4,200 lines.

Changes

Splits the monolithic provider validation service into 7 domain-focused files inside src/lib/providers/validation/:

File	Contents
utils.ts	URL normalizers, custom headers generation, safe outbound fetch wrappers
enterprise.ts	AWS, Azure, GCP, OCI, SAP, Heroku, Databricks, Snowflake, DataRobot
standard.ts	OpenAI-compatible, Anthropic-compatible, Gemini-compatible APIs
specialty.ts	Voice, Video, specialized text providers (Deepgram, AssemblyAI, Gigachat, etc.)
search.ts	Generic search validators and configuration constants
web.ts	Meta AI base62 helpers and web/cookie-auth providers (DeepSeekWeb, GrokWeb, Copilot, etc.)
core.ts	The main validateProviderApiKey switch dispatcher
index.ts	Re-exports everything cleanly

Results

• validation.ts: 4,200 lines → 1 line (re-exports validation/index.ts)
• All imports between files are resolved correctly.
• Full backward compatibility: all exports are preserved through the facade.

Verification

• npm run typecheck:core — passes cleanly.
• npx eslint src/lib/providers/validation/*.ts — 0 errors or warnings.
• Strictly structural refactoring with identical runtime behavior.

Resolves part of #3594.

[gemini-code-assist]

Code Review

This pull request modularizes the chatCore handler and combo services, implements legacy text-completion transformations for /v1/completions, adds missing API endpoints for gamification and agent-bridge testing, and introduces comprehensive UI panels for provider and model management. The code review identified critical security vulnerabilities, including a lack of authentication on the new upstream CA test route (exposing a local file probing risk) and prototype pollution risks in dynamic validator lookups. Additionally, the feedback highlights potential runtime crashes due to unsafe request body property access in combo handlers, a Next.js hydration mismatch from rendering dynamic dates, and a compatibility recommendation to explicitly import crypto.

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]

This route lacks any authentication or authorization checks, exposing it to potential unauthorized access. Since it accepts an arbitrary file path (caPath) and checks for its existence/readability, an attacker could exploit this to probe the existence of sensitive files on the local filesystem (Local File Inclusion / Information Disclosure). Please add the standard requireManagementAuth check at the beginning of the handler and import it from @/lib/api/requireManagementAuth.

export async function POST(request: Request): Promise<Response> {
  const authError = await requireManagementAuth(request);
  if (authError) return authError;

[gemini-code-assist]

Initializing state with a value derived from Date.now() during render can cause a hydration mismatch in Next.js, as the server-rendered time will differ from the client-side hydration time. Initialize tokenMinsLeft to null instead. The useEffect hook on mount will immediately trigger update() and set the correct client-side value.

Suggested change

	const [tokenMinsLeft, setTokenMinsLeft] = useState<number | null>(getTokenMinsLeft);
	const [tokenMinsLeft, setTokenMinsLeft] = useState<number | null>(null);

[gemini-code-assist]

The global crypto object is used throughout this file (e.g., crypto.getRandomValues, crypto.randomUUID). While globalThis.crypto is available in newer Node.js versions, explicitly importing crypto from node:crypto ensures compatibility with older environments and prevents potential ReferenceError or linter/bundler warnings.

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

[gemini-code-assist]

Accessing dynamic keys directly on a plain object (e.g., SPECIALTY_VALIDATORS[provider]) poses a prototype pollution or property injection risk if provider matches built-in properties like toString or hasOwnProperty. Use Object.prototype.hasOwnProperty.call to safely verify that the property is an own property of the object before accessing or calling it.

Suggested change

	if (SPECIALTY_VALIDATORS[provider]) {
	if (Object.prototype.hasOwnProperty.call(SPECIALTY_VALIDATORS, provider)) {

[gemini-code-assist]

Accessing dynamic keys directly on a plain object (e.g., SEARCH_VALIDATOR_CONFIGS[provider]) poses a prototype pollution or property injection risk if provider matches built-in properties like toString or hasOwnProperty. Use Object.prototype.hasOwnProperty.call to safely verify that the property is an own property of the object before accessing it.

  const config = Object.prototype.hasOwnProperty.call(SEARCH_VALIDATOR_CONFIGS, provider)
    ? SEARCH_VALIDATOR_CONFIGS[provider]
    : null;

[gemini-code-assist]

If body is null or undefined at runtime, casting it to Record<string, unknown> and accessing .max_tokens will throw a TypeError. Use optional chaining (body?.max_tokens) to safely handle potentially null or undefined request bodies.

Suggested change

	const currentMaxTokens = Number((body as Record<string, unknown>).max_tokens) || 0;
	const currentMaxTokens = Number(body?.max_tokens) || 0;

[gemini-code-assist]

If attemptBody is null or undefined at runtime, casting it to Record<string, unknown> and accessing .max_tokens will throw a TypeError. Use optional chaining (attemptBody?.max_tokens) to safely handle potentially null or undefined request bodies.

Suggested change

	// ALL max_tokens for reasoning_tokens, leaving content empty. Add a buffer
	const currentMaxTokens = Number(attemptBody?.max_tokens) || 0;

[diegosouzapw]

Thanks @oyi77 for the modularization work on src/lib/providers/validation.ts (Issue #3594). I can't merge this as it currently stands — and the reason is structural, not about the quality of the split:

1. It's a stacked/cumulative chain. This branch carries ~49–55 commits all starting from chore(release): open v3.8.23 development cycle, and the per-PR additions grow monotonically (refactor: modularize providerRegistry.ts (Issue #3594) #3617 ≈ +22k → refactor: modularize 3.1K-line providers.ts constants (Issue #3594) #3646 ≈ +52k). Each refactor branch is built on top of the previous one, so merging any single PR drags in all the earlier refactors too. That makes each PR impossible to review in isolation and guarantees conflicts between them.

2. The base is stale (v3.8.23 era). Since these were cut, release/v3.8.24 has merged dozens of PRs — including changes to the very files several of these PRs modularize (e.g. providerRegistry.ts grew via fix(providers): correct Ollama Cloud kimi-k2.7-code capabilities (#3761) #3768, validation.ts via fix(providers): repair qwen-web validation + stop mislabeling benign redirects as SSRF (#3288, #3758) #3767, plus combo/stream/usage edits). GitHub now reports this PR as CONFLICTING, and the conflicts are substantial.

What would let this land: re-cut it as a single, independent PR branched from the current release/v3.8.24 tip, modularizing only src/lib/providers/validation.ts (not stacked on the other refactors), small enough to review on its own. One file per PR, rebased on current release. I'll gladly review and merge them in that form — the god-file modularization goal is worth it; it's the 14-deep stack on a 2-week-old base that can't go in. Leaving this open so nothing is lost.

[oyi77]

Closed in favor of clean re-cut — see #3793 (providerRegistry), #3798 (combo), #3797 (validation), #3796 (imageGeneration), #3795 (usage), #3794 (providers). Only modularization commits were cherry-picked onto current release/v3.8.24 — no stacked dependencies, no unrelated changes.