[oyi77]

Summary

This PR addresses the highest priority massive file from Issue #3594: src/app/(dashboard)/dashboard/providers/[id]/page.tsx at 12,882 lines — the largest file in the entire codebase.

Changes

Splits the monolithic page component into 6 domain-focused files organized by responsibility:

File	Lines	Contents
types.ts	392	All shared interfaces and type definitions
utils.tsx	1,377	Helper functions + utility components (ModelSourceBadge, CooldownTimer, ModelCompatPopover, etc.)
modelManagement.tsx	1,645	ModelRow, ModelVisibilityToolbar, PassthroughModelsSection, CustomModelsSection, CompatibleModelsSection
connectionManagement.tsx	2,038	ConnectionRow, EditConnectionModal, EditCompatibleNodeModal
authModals.tsx	2,909	AddApiKeyModal, SiliconFlowEndpointModal, Import/Apply auth modals (Codex/Claude/Gemini)
playground.tsx	118	ProviderPlaygroundPanel, renderKindPanel

Results

• page.tsx: 12,882 → 4,687 lines (63% reduction)
• Each extracted file is < 3,000 lines and focused on a single domain
• Imports are automatically pruned per file — no unused imports
• Full backward compatibility: every symbol is re-exported via import

Verification

• npm run typecheck:core — passes
• ESLint — 0 errors, only 3 pre-existing hook-dependency warnings in page.tsx
• No behavioral changes — strict structural refactoring only

Resolves part of #3594.

[gemini-code-assist]

Code Review

This pull request soft-deprecates @omniroute/opencode-provider in favor of @omniroute/opencode-plugin, introduces CLI shorthands for autostart, implements real guardrail API endpoints, secures public OAuth client IDs, adds a max_tokens buffer for reasoning models, and translates chat responses back to the legacy text-completion shape for /v1/completions. The code review feedback highlights critical issues, including potential browser-side ReferenceErrors due to Buffer usage in client-side components, strict-mode TypeScript compilation errors from unknown type annotations in the modularized chatCore handlers, unnecessary CPU overhead from infinite interval timers, and a state-mutation bug in the single-model execution path.

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]

Using Buffer in a client-side React component ("use client") will cause a runtime ReferenceError: Buffer is not defined in browser environments where Buffer is not globally polyfilled. Since this is a client-side utility file, we should use the standard browser-safe atob function to decode the base64url-encoded JWT payload.

function extractEmailFromJwtLocal(idToken: string): string | null {
  try {
    const parts = idToken.split(".");
    if (parts.length !== 3) return null;
    const base64 = parts[1].replace(/-/g, "+").replace(/_/g, "/");
    const padded = base64.padEnd(base64.length + (4 - base64.length % 4) % 4, "=");
    const payload = JSON.parse(atob(padded));
    return typeof payload.email === "string" ? payload.email : null;
  } catch {
    return null;
  }
}

[gemini-code-assist]

Using Buffer in a client-side React component ("use client") will cause a runtime ReferenceError: Buffer is not defined in browser environments where Buffer is not globally polyfilled. Since this is a client-side utility file, we should use the standard browser-safe atob function to decode the base64url-encoded JWT payload.

function extractEmailFromGeminiJwt(idToken: string): string | null {
  try {
    const parts = idToken.split(".");
    if (parts.length !== 3) return null;
    const base64 = parts[1].replace(/-/g, "+").replace(/_/g, "/");
    const padded = base64.padEnd(base64.length + (4 - base64.length % 4) % 4, "=");
    const payload = JSON.parse(atob(padded));
    return typeof payload.email === "string" ? payload.email : null;
  } catch {
    return null;
  }
}

[gemini-code-assist]

Typing clientRawRequest and log as unknown will cause TypeScript compilation errors under strict mode when accessing properties like clientRawRequest?.headers or calling log?.debug?.(...). We should type them as any to allow dynamic property access and method calls.

Suggested change

	clientRawRequest: unknown;
	provider: string;
	model: string;
	effectiveServiceTier: unknown;
	startTime: number;
	log: unknown;
	}) {
	clientRawRequest: any;
	provider: string;
	model: string;
	effectiveServiceTier: any;
	startTime: number;
	log: any;
	}) {

[gemini-code-assist]

Typing body as Record<string, unknown>, and clientRawRequest, reqLogger, and log as unknown will cause TypeScript compilation errors under strict mode when accessing properties like body.messages, clientRawRequest?.headers, or calling reqLogger.logConvertedResponse(...) and log?.debug?.(...). We should type them as any to allow dynamic property access and method calls.

Suggested change

	semanticCacheEnabled: boolean;
	body: Record<string, unknown>;
	clientRawRequest: unknown;
	model: string;
	provider: string;
	stream: boolean;
	reqLogger: unknown;
	effectiveServiceTier: unknown;
	connectionId: string | null;
	startTime: number;
	log: unknown;
	persistAttemptLogs: (args: unknown) => void;
	}) {
	semanticCacheEnabled: boolean;
	body: any;
	clientRawRequest: any;
	model: string;
	provider: string;
	stream: boolean;
	reqLogger: any;
	effectiveServiceTier: any;
	connectionId: string | null;
	startTime: number;
	log: any;
	persistAttemptLogs: (args: any) => void;
	}) {

[gemini-code-assist]

Typing body as Record<string, unknown> and log as unknown will cause TypeScript compilation errors under strict mode when accessing properties like body.messages, body.input, body.tools, or calling log?.debug?.(...). We should type them as any to allow dynamic property access and method calls.

Suggested change

	}: {
	body: Record<string, unknown>;
	memoryOwnerId: string | null;
	provider: string;
	effectiveModel: string;
	sourceFormat: string;
	targetFormat: string;
	backgroundReason: string | null;
	log: unknown;
	}) {
	}: {
	body: any;
	memoryOwnerId: string | null;
	provider: string;
	effectiveModel: string;
	sourceFormat: string;
	targetFormat: string;
	backgroundReason: string | null;
	log: any;
	}) {

[gemini-code-assist]

Typing body as Record<string, unknown> will cause TypeScript compilation errors under strict mode when accessing, mutating, or deleting properties like body.max_output_tokens, body.max_completion_tokens, body.max_tokens, body.messages, body.input, and body.tools. We should type body as any to allow dynamic property access and mutations.

Suggested change

	export function sanitizeChatRequestBody(
	body: Record<string, unknown>,
	sourceFormat: string,
	targetFormat: string
	): Record<string, unknown> {
	export function sanitizeChatRequestBody(
	body: any,
	sourceFormat: string,
	targetFormat: string
	): any {

[gemini-code-assist]

If connection.rateLimitedUntil is in the past, the interval timer is still created and runs every second indefinitely, repeatedly setting isCooldown to false. This causes unnecessary CPU overhead. We should only create the interval if the cooldown is actually in the future, and clear it as soon as the cooldown expires.

  useEffect(() => {
    let interval: any = null;
    const checkCooldown = () => {
      const cooldown =
        connection.rateLimitedUntil && new Date(connection.rateLimitedUntil).getTime() > Date.now();
      setIsCooldown(cooldown);
      if (!cooldown && interval) {
        clearInterval(interval);
        interval = null;
      }
    };

    checkCooldown();
    const cooldownActive =
      connection.rateLimitedUntil && new Date(connection.rateLimitedUntil).getTime() > Date.now();
    if (cooldownActive) {
      interval = setInterval(checkCooldown, 1000);
    }
    return () => {
      if (interval) clearInterval(interval);
    };
  }, [connection.rateLimitedUntil]);

[gemini-code-assist]

If the cooldown has already expired initially (or once it expires), the setInterval timer continues to run every second indefinitely. We should only create the interval if the cooldown is in the future, and clear it as soon as the remaining time reaches zero.

  useEffect(() => {
    let interval: any = null;
    const updateRemaining = () => {
      const diff = new Date(until).getTime() - Date.now();
      if (diff <= 0) {
        setRemaining("");
        if (interval) {
          clearInterval(interval);
          interval = null;
        }
        return;
      }
      const secs = Math.floor(diff / 1000);
      if (secs < 60) {
        setRemaining(`${secs}s`);
      } else if (secs < 3600) {
        setRemaining(`${Math.floor(secs / 60)}m ${secs % 60}s`);
      } else {
        const hrs = Math.floor(secs / 3600);
        const mins = Math.floor((secs % 3600) / 60);
        setRemaining(`${hrs}h ${mins}m`);
      }
    };

    updateRemaining();
    const isActive = new Date(until).getTime() > Date.now();
    if (isActive) {
      interval = setInterval(updateRemaining, 1000);
    }
    return () => {
      if (interval) clearInterval(interval);
    };
  }, [until]);

[gemini-code-assist]

In the single-model section, attemptBody is cast to Record<string, unknown> and mutated directly (bodyRecord.max_tokens = bufferedMaxTokens;). This can cause the mutation to persist and potentially compound across retries or sibling calls. To prevent any side-effects, we should apply the buffer to a shallow copy of attemptBody, just like in the round-robin section.

          if (supportsReasoning(modelStr)) {
            const currentMaxTokens = Number((attemptBody as Record<string, unknown>).max_tokens) || 0;
            if (currentMaxTokens > 0) {
              const bufferedMaxTokens = Math.max(
                currentMaxTokens + 1000,
                Math.ceil(currentMaxTokens * 1.5)
              );
              attemptBody = {
                ...(attemptBody as Record<string, unknown>),
                max_tokens: bufferedMaxTokens,
              } as typeof attemptBody;
              log.info(
                "COMBO",
                `Reasoning model ${modelStr}: buffered max_tokens ${currentMaxTokens} -> ${bufferedMaxTokens}`
              );
            }
          }

[diegosouzapw]

Hi @oyi77 — thank you for taking on the single biggest file in the repo. Tackling providers/[id]/page.tsx (12,882 LOC) is exactly the kind of high-impact cleanup the project needs, and we're going to leverage part of this effort as we land the decomposition.

To keep everyone aligned, here's a detailed picture of what this PR does versus what's planned and now in progress under the tracking issue #3501 (which carries the owner-approved 6-phase plan).

What this PR does

• Splits page.tsx into 6 sibling files (types.ts, utils.tsx, modelManagement.tsx, connectionManagement.tsx, authModals.tsx, playground.tsx).
• Reduces page.tsx from 12,882 → 4,687 LOC, with symbols re-exported for backward compatibility.
• typecheck:core passes; ESLint clean apart from pre-existing warnings.

What the #3501 plan calls for (and how we're landing it)

The registered plan follows the repo's existing big-page convention and a strangler-fig sequence so each step is independently shippable and the check-file-size ratchet drops monotonically:

1. Thin page.tsx → ProviderDetailPageClient.tsx wrapper (the convention used by EndpointPageClient/ApiManagerPageClient), rather than keeping a 4,687-LOC page.tsx.
2. Colocated components/ + hooks/ subfolders (the providers/ route already uses this), rather than flat sibling files.
3. Extracting the data-fetching/state into custom hooks (useProviderConnections, useProviderModelMeta, …) so the ~195 useState / 87 inline fetch() calls collapse behind typed hooks — this is the part that actually de-risks future edits.
4. A smoke render test first (the page had zero tests) as the safety net every extraction phase is diffed against — Hard Rule fix(oauth): prevent connection test from corrupting valid tokens #8.
5. One phase per PR, each lowering the frozen check-file-size entry, so the file shrinks monotonically toward the ≤800-LOC cap.

We've started shipping these against the active release/v3.8.22 branch: Phase 0 (thin ProviderDetailPageClient + first smoke test) and Phase 1a (extracting the Codex/Claude/Gemini auth-import modal clusters into components/modals/) are merged, with later phases (presentational sub-components, helpers→lib/, hooks, render split) following the same pattern. You're credited as co-author on these for the parallel effort.

One heads-up on this branch

This PR currently targets main and its base predates the v3.8.21/v3.8.22 release work, so its diff also reverts ~70 unrelated files (recent release hardening, i18n changelogs, etc.). That, plus the structural differences above, is why we're aligning to the phased plan rather than merging this branch directly.

Thanks again — the grouping of symbols here was a useful reference. Follow #3501 to track the remaining phases.

---

This is an automated message from the quality-gate workflow.

[diegosouzapw]

Hi @oyi77 — thank you for taking the time to tackle this big refactor 🙏

We've now completed the providers/[id] god-component decomposition directly on the release branch, shipped in v3.8.22 under issue #3501, using a phased strangler-fig approach:

• Phase 0–1b: thin page.tsx → ProviderDetailPageClient + auth-import modals + EditCompatibleNodeModal
• Phase 2: pure helpers → cycle-safe leaf module
• Phase 1c: AddApiKeyModal + EditConnectionModal
• Phase 1d: ConnectionRow + ModelCompatPopover + SiliconFlowEndpointModal
• Phase 1e: useModelCompatState hook + the model sections
• Phase 1f: useProviderConnections / useProviderSettings / useProviderModels hooks

Result: 12,882 → 4,062 LOC (−68%) so far, fully cycle-checked, with smoke tests at every step and the file-size ratchet enforcing it stays shrunk.

Because the work landed phase-by-phase on the release branch (each phase independently typechecked/tested/merged), this PR is now superseded — so I'm closing it. You're credited as co-author on every #3501 phase commit, so your contribution is on the record. Thanks again for pushing on this, and please keep the PRs coming! 🚀