refactor: modularize 3.1K-line providers.ts constants (Issue #3594)

[oyi77]

Summary

This PR addresses the final High Priority massive file from Issue #3594: src/shared/constants/providers.ts at 3,122 lines.

Changes

Splits the monolithic configuration dictionary into 12 domain-focused files inside src/shared/constants/providers/:

File	Contents
types.ts, utils.ts, groups.ts	Provider definition types, runtime boolean flags, filter sets
core.ts	getProviderById, map initializers, and static dictionaries
definitions/apiKey.ts	The massive APIKEY_PROVIDERS definition block
definitions/oauth.ts, definitions/webCookie.ts, definitions/local.ts	Specialized auth providers
definitions/search.ts, definitions/audio.ts, definitions/noauth.ts	Other discrete provider buckets
definitions/compatible.ts	Dynamic and pass-through compat mappings
index.ts	Re-exports everything cleanly

Results

• providers.ts: 3,122 lines → 1 line (re-exports providers/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/shared/constants/providers/**/*.ts — 0 errors or warnings.
• Strictly structural refactoring with identical runtime behavior.

Resolves part of #3594.

[gemini-code-assist]

Code Review

This pull request introduces a major restructuring of the open-sse services, modularizing the monolithic chatCore handler, image generation handlers, usage fetchers, and combo routing services into dedicated sub-modules. It also soft-deprecates @omniroute/opencode-provider in favor of @omniroute/opencode-plugin, cleans up fictional endpoints in the API reference, migrates public OAuth client IDs to secure resolvers, and fixes bugs related to reasoning models and unclosed reasoning tags. The code review identified several critical issues: a missing await on an asynchronous database query in the Xiaomi usage fetcher that causes incorrect token tracking; a missing check for job_id in the Haiper image generation handler that can lead to malformed polling URLs; overwriting of rate limit keys in the Kimi usage fetcher loop; and a potential RangeError in parseResetTime when handling invalid dates.

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]

Since getMonthlyProviderTokensForConnection is imported from @/lib/usage/usageStats and likely performs asynchronous database queries, it should be awaited. Otherwise, used will be a Promise object, which toNumber (inside createQuotaFromUsage) will parse as NaN and default to 0, resulting in incorrect usage tracking.

    const used = await getMonthlyProviderTokensForConnection("xiaomi-mimo", connectionId);

[gemini-code-assist]

If res.json() does not contain job_id (e.g., due to an unexpected upstream response format or API error), job_id will be undefined. This will cause the subsequent polling loop to request a malformed URL (${providerConfig.statusUrl}/undefined), leading to unnecessary network requests and a less clear error. We should explicitly check for job_id and return a proper 502 error if it is missing.

    const { job_id } = await res.json();
    if (!job_id) {
      const errorText = "No job ID returned from Haiper";
      saveCallLog({
        method: "POST",
        path: "/v1/images/generations",
        status: 502,
        model: `${provider}/${model}`,
        provider,
        duration: Date.now() - startTime,
        error: errorText,
      }).catch(() => {});
      return { success: false, status: 502, error: errorText };
    }

[gemini-code-assist]

If limitsArray contains multiple rate limit objects (e.g., different windows or types), they will all overwrite quotas["Ratelimit"] in the loop, meaning only the last one will be preserved. We should use a unique key (such as appending the index or window duration) to ensure all rate limits are captured and displayed.

        const quotaKey = limitsArray.length > 1 ? `Ratelimit #${i + 1}` : "Ratelimit";
        quotas[quotaKey] = {
          used: limit - remaining,
          total: limit,
          remaining,
          remainingPercentage: limit > 0 ? (remaining / limit) * 100 : 0,
          resetAt: parseResetTime(resetTime),
          unlimited: false,
        };

[gemini-code-assist]

In parseResetTime, calling date.getTime() <= 0 is false when date is an Invalid Date (since NaN <= 0 is false). This causes the function to proceed to date.toISOString(), which throws a RangeError: Invalid time value. Although this is caught by the try-catch block, it is cleaner and more performant to explicitly check Number.isNaN(time) to avoid throwing and catching exceptions for malformed date strings.

Suggested change

	// Epoch-zero (1970-01-01) means no scheduled reset — treat as null
	if (date.getTime() <= 0) return null;
	// Epoch-zero (1970-01-01) means no scheduled reset — treat as null
	const time = date.getTime();
	if (Number.isNaN(time) || time <= 0) return null;

[diegosouzapw]

Thanks @oyi77 for the modularization work on src/shared/constants/providers.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/shared/constants/providers.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.