Skip to content

fix: relax provider routing rule limits#1000

Merged
ding113 merged 2 commits intodevfrom
fix/relax-config-limits
Apr 8, 2026
Merged

fix: relax provider routing rule limits#1000
ding113 merged 2 commits intodevfrom
fix/relax-config-limits

Conversation

@ding113
Copy link
Copy Markdown
Owner

@ding113 ding113 commented Apr 8, 2026

Summary

Raise provider model redirect and allowlist rule caps from 100 to 100,000 entries, increase per-rule text length cap from 255 to 4,096 characters, and centralize both limits through a shared PROVIDER_RULE_LIMITS constant. Updates editor-level guards, server-side Zod schemas, i18n copy across all 5 languages, and adds regression tests for the relaxed limits.

Problem

The previous hard-coded limits of 100 rules and 255-character text fields were too restrictive for large-scale routing tables (e.g., organizations with many model variants or complex regex-based routing patterns). Both the frontend editors and backend schemas enforced these low caps independently with duplicated magic numbers.

Solution

  • Introduced a single PROVIDER_RULE_LIMITS constant in src/lib/constants/provider.constants.ts with MAX_ITEMS: 100_000 and MAX_TEXT_LENGTH: 4_096
  • Updated both editor components (allowed-model-rule-editor.tsx, model-redirect-editor.tsx) to reference the shared constant instead of inline 100 / 255 values
  • Updated all Zod validation schemas (provider-allowed-model-schema.ts, provider-model-redirect-schema.ts) to use the same constant
  • Parameterized i18n strings across all 5 languages (zh-CN, zh-TW, en, ja, ru) with {max} interpolation so limit values stay in sync automatically

Changes

Core Changes

  • src/lib/constants/provider.constants.ts -- Added PROVIDER_RULE_LIMITS constant (MAX_ITEMS: 100_000, MAX_TEXT_LENGTH: 4_096)
  • src/lib/provider-allowed-model-schema.ts -- Updated .max() calls on both rule array and pattern string to use the shared constant
  • src/lib/provider-model-redirect-schema.ts -- Updated .max() calls on rule array, source, and target strings to use the shared constant
  • src/app/[locale]/settings/providers/_components/allowed-model-rule-editor.tsx -- Replaced inline 100 / 255 with PROVIDER_RULE_LIMITS; passes {max} to i18n messages
  • src/app/[locale]/settings/providers/_components/model-redirect-editor.tsx -- Same treatment for redirect editor

i18n Updates

  • Updated maxRules, patternTooLong, sourceTooLong, targetTooLong, and quickAddReachedLimit messages in all 5 languages to use {max} interpolation instead of hard-coded numbers

Tests Added

  • tests/unit/lib/provider-allowed-model-schema.test.ts (new) -- Verifies patterns up to 4,096 chars are accepted; validates 100,000-entry list passes and 100,001-entry list is rejected
  • tests/unit/lib/provider-model-redirect-schema.test.ts (new) -- Same boundary tests for redirect rules
  • tests/unit/settings/providers/allowed-model-rule-editor.test.tsx -- New test proving 100+ rules no longer block the add button
  • tests/unit/settings/providers/model-redirect-editor.test.tsx -- New test proving 100+ redirect rules can still be added; updated existing length validation test to reflect the new 4,097-char boundary

Breaking Changes

None. The limits are only relaxed (widened), so all previously valid configurations remain valid. No exports were removed or renamed.

Testing

Automated Tests

  • Unit tests added for schema validation boundaries (both schemas)
  • Component tests added for editor limit enforcement (both editors)

Verification Commands

bunx vitest run tests/unit/settings/providers/model-redirect-editor.test.tsx \
  tests/unit/settings/providers/allowed-model-rule-editor.test.tsx \
  tests/unit/lib/provider-model-redirect-schema.test.ts \
  tests/unit/lib/provider-allowed-model-schema.test.ts
bun run lint:fix
bun run lint
bun run typecheck
bun run build

Notes

  • bun run test currently has existing suite-level failures on both this branch and untouched main, including tests/unit/actions/providers-undo-engine.test.ts and tests/unit/lib/provider-patch-contract.test.ts when run in the full suite. Those files pass in isolation on both trees, so this PR does not include a fix for that baseline issue.

Checklist

  • Code follows project conventions
  • Self-review completed
  • Tests pass locally
  • i18n strings updated for all 5 languages

Description enhanced by Claude AI

Greptile Summary

Raises provider routing rule caps from 100 → 100,000 entries and 255 → 4,096 characters by introducing a shared PROVIDER_RULE_LIMITS constant, then threading it through both Zod schemas, both editor components, and all 5 i18n locales. The approach is clean and internally consistent — the previous concerns about duplicated test constants and missing {max} interpolation are fully resolved in this version.

Confidence Score: 5/5

Safe to merge — all remaining findings are P2 suggestions with no correctness or data-integrity risk on the changed paths.

The constant centralization, schema updates, i18n changes, and tests are all well-executed. The only open finding is a P2 UX-performance note about the absence of list virtualization in the editors, which is a pre-existing architectural pattern rather than a regression introduced by this PR. No P0 or P1 issues were found.

No files require special attention for merge readiness. The editor components warrant a follow-up for list virtualization if large rule sets become common in practice.

Vulnerabilities

No security concerns identified. Regex inputs continue to be guarded by safeRegex (ReDoS protection) and schema-level superRefine on both editor and server-side paths. Relaxing the length cap to 4,096 characters does not introduce new injection vectors.

Important Files Changed

Filename Overview
src/lib/constants/provider.constants.ts New PROVIDER_RULE_LIMITS constant correctly centralizes MAX_ITEMS: 100_000 and MAX_TEXT_LENGTH: 4_096 for both schema and editor use.
src/lib/provider-allowed-model-schema.ts All .max() calls updated to use PROVIDER_RULE_LIMITS; consistent across INPUT_LIST_SCHEMA and LIST_SCHEMA variants.
src/lib/provider-model-redirect-schema.ts source/target .max() and list .max() all updated to use PROVIDER_RULE_LIMITS; no regressions introduced.
src/app/[locale]/settings/providers/_components/allowed-model-rule-editor.tsx Correctly uses PROVIDER_RULE_LIMITS and passes {max} to i18n; rule list rendering is unbounded and could freeze browsers at very high counts.
src/app/[locale]/settings/providers/_components/model-redirect-editor.tsx Same constant migration and i18n update as the allowlist editor; shares the same unvirtualized list render concern.
tests/unit/lib/provider-allowed-model-schema.test.ts Imports limits from source constant (no duplication); covers acceptance at cap and rejection at cap+1, but lacks the negative boundary test for pattern length (noted in prior thread).
tests/unit/lib/provider-model-redirect-schema.test.ts Same structure as the allowlist schema test; imports from constants; same gap with missing rejection tests for oversized source/target (noted in prior thread).
tests/unit/settings/providers/model-redirect-editor.test.tsx Adds regression tests for 100+ rules and the new 4097-char boundary; existing edit-while-delete test retained.
tests/unit/settings/providers/allowed-model-rule-editor.test.tsx New test confirms 100+ rules no longer block the add button; existing add/edit/picker tests retained and passing.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[PROVIDER_RULE_LIMITS\nMAX_ITEMS 100000\nMAX_TEXT_LENGTH 4096] --> B[provider-allowed-model-schema.ts\n.max on pattern + list]
    A --> C[provider-model-redirect-schema.ts\n.max on source, target + list]
    A --> D[allowed-model-rule-editor.tsx\nUI guard + i18n interpolation]
    A --> E[model-redirect-editor.tsx\nUI guard + i18n interpolation]
    B --> F[(JSONB: allowed_models\nPostgreSQL)]
    C --> G[(JSONB: model_redirects\nPostgreSQL)]
    D --> H[i18n messages\nzh-CN / zh-TW / en / ja / ru]
    E --> H
Loading
Prompt To Fix All With AI
This is a comment left during a code review.
Path: src/app/[locale]/settings/providers/_components/allowed-model-rule-editor.tsx
Line: 358-501

Comment:
**No list virtualization for the new 100k-item limit**

Both editor components render every rule as a DOM element inside a plain `.map()`. With `MAX_ITEMS` raised to 100,000, a user who imports a large routing table could render tens of thousands of nodes, causing the browser to freeze or OOM before they even approach the cap. The same applies to `model-redirect-editor.tsx` at its corresponding list render.

Consider adding a virtualized list (e.g., `react-window` or `@tanstack/react-virtual`) when `value.length` exceeds a practical rendering threshold (e.g., 500), or capping the *UI-visible* list while keeping the schema limit unrestricted. As it stands, the relaxed schema limit and the unguarded DOM render are mismatched.

How can I resolve this? If you propose a fix, please make it concise.

Reviews (2): Last reviewed commit: "test: reuse provider rule limit constant..." | Re-trigger Greptile

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 8, 2026

📝 Walkthrough

Walkthrough

此 PR 将硬编码的规则数与文本长度限制替换为导出的 PROVIDER_RULE_LIMITS 常量,并将多个 i18n 文本改为使用 {max} 占位符;相应的验证 schema、编辑器组件及若干单元测试已同步更新以使用新常量与参数化消息。(不超过 50 字)

Changes

Cohort / File(s) Summary
国际化消息
messages/en/settings/providers/form/allowedModelRules.json, messages/en/settings/providers/form/modelRedirect.json, messages/ja/settings/providers/form/allowedModelRules.json, messages/ja/settings/providers/form/modelRedirect.json, messages/ru/settings/providers/form/allowedModelRules.json, messages/ru/settings/providers/form/modelRedirect.json, messages/zh-CN/settings/providers/form/allowedModelRules.json, messages/zh-CN/settings/providers/form/modelRedirect.json, messages/zh-TW/settings/providers/form/allowedModelRules.json, messages/zh-TW/settings/providers/form/modelRedirect.json
将硬编码的数值限制(例如“100”或固定字符数提示)替换为 {max} 占位符,消息文本改为参数化显示最大值。
常量定义
src/lib/constants/provider.constants.ts
新增导出常量 PROVIDER_RULE_LIMITSMAX_ITEMS: 100_000MAX_TEXT_LENGTH: 4_096(使用 as const)。
Schema 验证
src/lib/provider-allowed-model-schema.ts, src/lib/provider-model-redirect-schema.ts
将 schema 中的 .max(100, ...).max(255, ...) 等硬编码限制替换为 PROVIDER_RULE_LIMITS 对应字段,并更新错误信息以包含动态最大值。
编辑器组件
src/app/[locale]/settings/providers/_components/allowed-model-rule-editor.tsx, src/app/[locale]/settings/providers/_components/model-redirect-editor.tsx
组件使用 PROVIDER_RULE_LIMITS 代替硬编码常量,验证与添加逻辑改为参照新常量,并在 i18n 调用中传入 { max } 插值数据。
单元测试
tests/unit/lib/provider-allowed-model-schema.test.ts, tests/unit/lib/provider-model-redirect-schema.test.ts, tests/unit/settings/providers/allowed-model-rule-editor.test.tsx, tests/unit/settings/providers/model-redirect-editor.test.tsx
新增/更新测试以覆盖基于 PROVIDER_RULE_LIMITS 的边界行为(文本最大长度、列表最大项数)和组件在接近/达到限制时的交互。

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed Pull request title 'fix: relax provider routing rule limits' clearly and specifically summarizes the main change: raising provider routing rule limits from 100 to 100,000 and text field limits from 255 to 4,096 characters.
Description check ✅ Passed The pull request description clearly relates to the changeset, describing increases to provider rule limits and the introduction of a centralized PROVIDER_RULE_LIMITS constant.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/relax-config-limits

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@github-actions github-actions Bot added the size/M Medium PR (< 500 lines) label Apr 8, 2026
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request replaces hardcoded limits for provider allowlist and redirect rules with dynamic constants, increasing the maximum allowed items to 100,000 and the text length to 4,096 characters across localization files, UI components, and validation schemas. While the change provides more flexibility, a significant performance risk was identified: rendering and validating 100,000 complex React components or large JSON payloads could lead to browser crashes, API timeouts, or DoS vulnerabilities. It is recommended to implement UI virtualization and more efficient validation if such high limits are truly necessary.


export const PROVIDER_RULE_LIMITS = {
// 模型白名单 / 重定向规则保存在 JSONB 中,这里统一放宽到支持大规模路由表
MAX_ITEMS: 100_000,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

Increasing MAX_ITEMS to 100,000 entries introduces significant performance and stability risks with the current implementation:

  1. UI Performance: The AllowedModelRuleEditor and ModelRedirectEditor components render the entire list using .map(). Rendering 100,000 complex React components (with inputs, selects, and buttons) will likely cause the browser to hang or crash. UI virtualization (e.g., react-window) is necessary for lists of this size.
  2. Validation Overhead: Zod validation of 100,000 items, especially with superRefine calling safe-regex on each entry, will block the Node.js event loop, potentially leading to API timeouts or service unavailability (DoS risk).
  3. Payload Size: A 100k-entry JSON object can be several megabytes, which may exceed default request body limits in proxies or application servers.

Consider if such a high limit is truly required, or implement the necessary optimizations (virtualization, efficient validation) alongside this change.

Comment on lines +7 to +8
const MAX_PROVIDER_RULES = 100_000;
const MAX_PROVIDER_RULE_TEXT_LENGTH = 4_096;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Test limits not imported from source constant

MAX_PROVIDER_RULES and MAX_PROVIDER_RULE_TEXT_LENGTH duplicate the values from PROVIDER_RULE_LIMITS rather than importing them. If the constants are updated in the future the tests will silently continue asserting the old values, undermining their regression value.

Suggested change
const MAX_PROVIDER_RULES = 100_000;
const MAX_PROVIDER_RULE_TEXT_LENGTH = 4_096;
import { PROVIDER_RULE_LIMITS } from "@/lib/constants/provider.constants";
const MAX_PROVIDER_RULES = PROVIDER_RULE_LIMITS.MAX_ITEMS;
const MAX_PROVIDER_RULE_TEXT_LENGTH = PROVIDER_RULE_LIMITS.MAX_TEXT_LENGTH;

The same pattern applies in tests/unit/lib/provider-model-redirect-schema.test.ts lines 7–8.

Prompt To Fix With AI
This is a comment left during a code review.
Path: tests/unit/lib/provider-allowed-model-schema.test.ts
Line: 7-8

Comment:
**Test limits not imported from source constant**

`MAX_PROVIDER_RULES` and `MAX_PROVIDER_RULE_TEXT_LENGTH` duplicate the values from `PROVIDER_RULE_LIMITS` rather than importing them. If the constants are updated in the future the tests will silently continue asserting the old values, undermining their regression value.

```suggestion
import { PROVIDER_RULE_LIMITS } from "@/lib/constants/provider.constants";

const MAX_PROVIDER_RULES = PROVIDER_RULE_LIMITS.MAX_ITEMS;
const MAX_PROVIDER_RULE_TEXT_LENGTH = PROVIDER_RULE_LIMITS.MAX_TEXT_LENGTH;
```

The same pattern applies in `tests/unit/lib/provider-model-redirect-schema.test.ts` lines 7–8.

How can I resolve this? If you propose a fix, please make it concise.

Comment on lines +17 to +25
describe("provider-allowed-model-schema", () => {
it("accepts match patterns longer than 255 characters when still within the new cap", () => {
const result = PROVIDER_ALLOWED_MODEL_RULE_SCHEMA.safeParse({
matchType: "exact",
pattern: "m".repeat(MAX_PROVIDER_RULE_TEXT_LENGTH),
});

expect(result.success).toBe(true);
});
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Missing rejection test for patternTooLong

The test suite verifies acceptance at exactly MAX_PROVIDER_RULE_TEXT_LENGTH characters but never asserts that MAX_PROVIDER_RULE_TEXT_LENGTH + 1 is rejected. Without the negative case there is no guard against someone accidentally removing or relaxing the .max() constraint on the pattern field. Consider adding:

it("rejects match patterns longer than the cap", () => {
  const result = PROVIDER_ALLOWED_MODEL_RULE_SCHEMA.safeParse({
    matchType: "exact",
    pattern: "m".repeat(MAX_PROVIDER_RULE_TEXT_LENGTH + 1),
  });
  expect(result.success).toBe(false);
});

The same gap exists in tests/unit/lib/provider-model-redirect-schema.test.ts for the source / target fields.

Prompt To Fix With AI
This is a comment left during a code review.
Path: tests/unit/lib/provider-allowed-model-schema.test.ts
Line: 17-25

Comment:
**Missing rejection test for `patternTooLong`**

The test suite verifies acceptance at exactly `MAX_PROVIDER_RULE_TEXT_LENGTH` characters but never asserts that `MAX_PROVIDER_RULE_TEXT_LENGTH + 1` is rejected. Without the negative case there is no guard against someone accidentally removing or relaxing the `.max()` constraint on the `pattern` field. Consider adding:

```ts
it("rejects match patterns longer than the cap", () => {
  const result = PROVIDER_ALLOWED_MODEL_RULE_SCHEMA.safeParse({
    matchType: "exact",
    pattern: "m".repeat(MAX_PROVIDER_RULE_TEXT_LENGTH + 1),
  });
  expect(result.success).toBe(false);
});
```

The same gap exists in `tests/unit/lib/provider-model-redirect-schema.test.ts` for the `source` / `target` fields.

How can I resolve this? If you propose a fix, please make it concise.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
tests/unit/lib/provider-model-redirect-schema.test.ts (1)

7-8: 建议测试直接复用 PROVIDER_RULE_LIMITS,避免常量漂移。

当前测试把 100000/4096 再写一遍,后续若调整限制,测试可能“意外通过但语义过时”。建议从 @/lib/constants/provider.constants 直接导入。

可参考改法
+import { PROVIDER_RULE_LIMITS } from "@/lib/constants/provider.constants";
 import { describe, expect, it } from "vitest";
 import {
   PROVIDER_MODEL_REDIRECT_RULE_LIST_SCHEMA,
   PROVIDER_MODEL_REDIRECT_RULE_SCHEMA,
 } from "@/lib/provider-model-redirect-schema";
 
-const MAX_PROVIDER_RULES = 100_000;
-const MAX_PROVIDER_RULE_TEXT_LENGTH = 4_096;
+const { MAX_ITEMS: MAX_PROVIDER_RULES, MAX_TEXT_LENGTH: MAX_PROVIDER_RULE_TEXT_LENGTH } =
+  PROVIDER_RULE_LIMITS;
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@tests/unit/lib/provider-model-redirect-schema.test.ts` around lines 7 - 8,
The test redefines numeric limits (MAX_PROVIDER_RULES,
MAX_PROVIDER_RULE_TEXT_LENGTH) which can drift from the real constants; instead
import and use the canonical PROVIDER_RULE_LIMITS from provider.constants (e.g.,
use PROVIDER_RULE_LIMITS.maxRules and PROVIDER_RULE_LIMITS.maxRuleTextLength) in
the test to ensure it always reflects the source-of-truth; replace occurrences
of MAX_PROVIDER_RULES and MAX_PROVIDER_RULE_TEXT_LENGTH in the test with the
corresponding fields from PROVIDER_RULE_LIMITS and remove the duplicated
constants.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/app/`[locale]/settings/providers/_components/model-redirect-editor.tsx:
- Around line 129-130: The current check against PROVIDER_RULE_LIMITS.MAX_ITEMS
and the full rendering of redirects in model-redirect-editor.tsx will not scale
to 100000 items; refactor the component to use a virtualized list (e.g.,
react-window/react-virtualized) or server-side pagination for the rendering
layer (replace full-map rendering of redirects) and add a cached Set of rule
keys used by validation logic (instead of scanning redirects linearly) so
methods that call setError / validate new entries consult the cached keys;
ensure functions/components like the list renderer and the validation helper
update the cache incrementally on add/edit/delete to avoid repeated O(n) scans.

---

Nitpick comments:
In `@tests/unit/lib/provider-model-redirect-schema.test.ts`:
- Around line 7-8: The test redefines numeric limits (MAX_PROVIDER_RULES,
MAX_PROVIDER_RULE_TEXT_LENGTH) which can drift from the real constants; instead
import and use the canonical PROVIDER_RULE_LIMITS from provider.constants (e.g.,
use PROVIDER_RULE_LIMITS.maxRules and PROVIDER_RULE_LIMITS.maxRuleTextLength) in
the test to ensure it always reflects the source-of-truth; replace occurrences
of MAX_PROVIDER_RULES and MAX_PROVIDER_RULE_TEXT_LENGTH in the test with the
corresponding fields from PROVIDER_RULE_LIMITS and remove the duplicated
constants.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f97dbe47-2aca-4714-bddb-ed8b5b3ff9a7

📥 Commits

Reviewing files that changed from the base of the PR and between 3d860b3 and 4e46e67.

📒 Files selected for processing (19)
  • messages/en/settings/providers/form/allowedModelRules.json
  • messages/en/settings/providers/form/modelRedirect.json
  • messages/ja/settings/providers/form/allowedModelRules.json
  • messages/ja/settings/providers/form/modelRedirect.json
  • messages/ru/settings/providers/form/allowedModelRules.json
  • messages/ru/settings/providers/form/modelRedirect.json
  • messages/zh-CN/settings/providers/form/allowedModelRules.json
  • messages/zh-CN/settings/providers/form/modelRedirect.json
  • messages/zh-TW/settings/providers/form/allowedModelRules.json
  • messages/zh-TW/settings/providers/form/modelRedirect.json
  • src/app/[locale]/settings/providers/_components/allowed-model-rule-editor.tsx
  • src/app/[locale]/settings/providers/_components/model-redirect-editor.tsx
  • src/lib/constants/provider.constants.ts
  • src/lib/provider-allowed-model-schema.ts
  • src/lib/provider-model-redirect-schema.ts
  • tests/unit/lib/provider-allowed-model-schema.test.ts
  • tests/unit/lib/provider-model-redirect-schema.test.ts
  • tests/unit/settings/providers/allowed-model-rule-editor.test.tsx
  • tests/unit/settings/providers/model-redirect-editor.test.tsx

Comment on lines +129 to +130
if (redirects.length >= PROVIDER_RULE_LIMITS.MAX_ITEMS) {
setError(t("maxRules", { max: PROVIDER_RULE_LIMITS.MAX_ITEMS }));
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

将前端可编辑上限放宽到 100000 会触发大列表性能瓶颈。

当前组件仍是全量渲染 + 多处线性操作;当规则规模接近新上限时,页面会出现明显卡顿甚至阻塞。建议至少补充分页/虚拟列表(渲染层)并缓存规则键集合(校验层),否则该上限在 UI 上不可用。

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/app/`[locale]/settings/providers/_components/model-redirect-editor.tsx
around lines 129 - 130, The current check against PROVIDER_RULE_LIMITS.MAX_ITEMS
and the full rendering of redirects in model-redirect-editor.tsx will not scale
to 100000 items; refactor the component to use a virtualized list (e.g.,
react-window/react-virtualized) or server-side pagination for the rendering
layer (replace full-map rendering of redirects) and add a cached Set of rule
keys used by validation logic (instead of scanning redirects linearly) so
methods that call setError / validate new entries consult the cached keys;
ensure functions/components like the list renderer and the validation helper
update the cache incrementally on add/edit/delete to avoid repeated O(n) scans.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4e46e673e9

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".


export const PROVIDER_RULE_LIMITS = {
// 模型白名单 / 重定向规则保存在 JSONB 中,这里统一放宽到支持大规模路由表
MAX_ITEMS: 100_000,
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Keep routing-rule cap within request-time matching budget

Raising MAX_ITEMS to 100,000 introduces a hot-path performance regression because request routing still does linear rule scans (matchesAllowedModelRules in provider selection and findMatchingProviderModelRedirectRule in redirect application), and regex rules are evaluated via matchesPattern without precompiled caches. With this cap, a single request can trigger huge per-request CPU work when providers carry large rule sets, which can noticeably degrade latency or cause timeouts under load; the higher cap should only ship with indexed/compiled matching (or a lower safe limit).

Useful? React with 👍 / 👎.

pattern: "",
};
const MAX_ALLOWED_MODEL_RULES = 100;
const MAX_ALLOWED_MODEL_RULES = PROVIDER_RULE_LIMITS.MAX_ITEMS;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Gate 100k UI rule cap behind virtualized rendering

The editors now permit 100,000 entries, but the settings UIs still render full rule arrays in normal React lists (no virtualization/pagination), so loading a provider with a very large routing table can lock up the browser before the user can edit anything. This makes the new limit practically unusable in the admin UI and should be paired with virtualized list rendering or a smaller UI-facing cap.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Contributor

@github-actions github-actions Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review Summary

No significant issues identified in this PR.

PR Size: M

  • Lines changed: 318
  • Files changed: 19

Review Coverage

  • Logic and correctness - Clean
  • Security (OWASP Top 10) - Clean
  • Error handling - Clean
  • Type safety - Clean
  • Documentation accuracy - Clean
  • Test coverage - Adequate
  • Code clarity - Good

Automated review by Codex AI

Copy link
Copy Markdown
Contributor

@github-actions github-actions Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Reviewed PR #1000 (fix: relax provider routing rule limits) across the 19 changed files and applied the size/M label.
  • No diff-scoped issues met the reporting threshold, so I did not post any inline review comments.
  • Submitted the PR-level review summary as a COMMENTED review via gh pr review.

@ding113 ding113 merged commit c48ec7f into dev Apr 8, 2026
8 of 10 checks passed
@github-project-automation github-project-automation Bot moved this from Backlog to Done in Claude Code Hub Roadmap Apr 8, 2026
@github-actions github-actions Bot mentioned this pull request Apr 13, 2026
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:i18n area:provider area:UI bug Something isn't working size/M Medium PR (< 500 lines)

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

1 participant