feat: allow failureThreshold to be zero or above 100

[TethysPlex]

Summary

Adds configuration flexibility to the circuit breaker's failureThreshold parameter, allowing values of 0 (to disable circuit breaking) and values above 100 (for high-tolerance scenarios).

Problem

The circuit breaker's failureThreshold was previously restricted to a rigid range of 1-100, preventing users from:

• Disabling circuit breaking entirely for trusted/stable providers
• Setting high tolerance thresholds (>100) for providers with expected high failure rates

This limitation was enforced at three layers:

1. Form validation (HTML input min="1" max="100")
2. Zod schema validation (min(1) and max(100))
3. No special handling logic in the circuit breaker core

Solution

This PR implements a three-part solution:

1. Validation Layer Changes

File: src/lib/validation/schemas.ts

• Relaxed CreateProviderSchema.circuit_breaker_failure_threshold from min(1).max(100) to min(0)
• Relaxed UpdateProviderSchema.circuit_breaker_failure_threshold from min(1).max(100) to min(0)
• Removed upper bound entirely to allow values >100

2. Circuit Breaker Logic Enhancement

File: src/lib/circuit-breaker.ts:248

• Added special case: if (config.failureThreshold > 0 && ...)
• When failureThreshold = 0, the circuit breaker will never open, effectively disabling it
• Previously, any failure count ≥ threshold would trigger circuit opening

3. UI/UX Safety Confirmation

File: src/app/[locale]/settings/providers/_components/forms/provider-form.tsx

• Added pre-submit validation to detect special values (0 or >100)
• Displays a confirmation dialog explaining the implications:
  • When 0: "禁用熔断器" (Disables circuit breaker) - provider will never be circuit-broken
  • When >100: Warns about high threshold and delayed circuit breaking
• Removed HTML max="100" constraint, changed min="1" to min="0"
• User must explicitly confirm before saving special configurations

Changes

Core Changes

• src/lib/circuit-breaker.ts (+2/-1): Add failureThreshold=0 bypass logic
• src/lib/validation/schemas.ts (+2/-4): Remove 1-100 range constraints

Supporting Changes

• src/app/[locale]/settings/providers/_components/forms/provider-form.tsx (+57/-2):
  • Add showFailureThresholdConfirm state and confirmation dialog
  • Add pre-submit check for special values
  • Update input constraints to allow min=0, no max
  • Extract submission logic to performSubmit() function

Use Cases

Scenario	failureThreshold	Behavior
Disable circuit breaking	0	Provider never gets circuit-broken, all failures are retried
Default behavior	5 (default)	Circuit opens after 5 consecutive failures (unchanged)
High tolerance	150	Circuit opens only after 150 consecutive failures

Testing

Automated Tests

Not applicable - no test files modified

Manual Testing Checklist

1. Navigate to provider settings form
2. Set failureThreshold to 0 → verify confirmation dialog appears with "禁用熔断器" message
3. Confirm save → verify no validation errors
4. Set failureThreshold to 150 → verify confirmation dialog warns about high threshold
5. Set failureThreshold to 5 → verify no confirmation dialog (normal value)
6. Verify circuit breaker with failureThreshold=0 never opens under failures

Notes

• Default value remains unchanged: The default failureThreshold is still 5 (defined in DEFAULT_CIRCUIT_BREAKER_CONFIG)
• No migration required: Existing providers with values 1-100 continue working identically
• UI language: Confirmation dialog is currently in Chinese only (follows existing i18n patterns in codebase)

---

Description enhanced by Claude AI

[gemini-code-assist]

Summary of Changes

Hello @TethysPlex, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

此拉取请求旨在增强熔断器失败阈值配置的灵活性。通过允许将阈值设置为0来完全禁用熔断器，或设置为大于100的值以适应更宽松的故障容忍度，系统能够更好地适应不同的服务提供商策略。此次更改涉及用户界面中对特殊值进行确认的提示，以及后端熔断逻辑和数据验证模式的相应调整，以确保新配置的正确性和健达性。

Highlights

• 熔断阈值范围扩展: 熔断器失败阈值（failureThreshold）现在可以设置为0（表示禁用熔断器）或大于100的值。此前，该值被限制在1到100之间。
• 特殊值确认对话框: 当用户将熔断阈值设置为0或大于100时，系统会弹出一个确认对话框，以提醒用户这些特殊配置的含义和潜在影响。
• 后端逻辑更新: 熔断器逻辑已更新，现在能够正确处理failureThreshold = 0的情况，即当阈值为0时，熔断器功能将被禁用。
• 验证模式调整: 相关的验证模式（CreateProviderSchema和UpdateProviderSchema）已修改，允许failureThreshold为0，并移除了上限100的限制。

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

此 PR 允许将熔断失败阈值 (failureThreshold) 设置为 0（禁用熔断器）或大于 100 的值。整体实现是正确的，涵盖了前端 UI、后端逻辑和数据验证。

主要变更包括：

1. 前端 (provider-form.tsx):
   • 更新了输入框的 min 属性并移除了 max 属性。
   • 增加了确认对话框，以便在用户设置特殊值（0 或 >100）时进行提醒，提升了用户体验。
2. 后端 (circuit-breaker.ts):
   • 修改了熔断逻辑，当 failureThreshold 为 0 时，熔断器不会被触发。
3. 数据验证 (schemas.ts):
   • 更新了 Zod schema，允许 failureThreshold 的值为 0，并取消了上限。

代码变更逻辑清晰，功能实现完整。我提出了一些关于前端代码实现的小建议，旨在提高代码的语义化和一致性，请查看具体的 review comments。

[greptile-apps]

Greptile found no issues!

From now on, if a review finishes and we haven't found any issues, we will not post anything, but you can confirm that we reviewed your changes in the status check section.

_{This feature can be toggled off in your Code Review Settings by deselecting "Create a status check for each PR".}

[github-actions]

[HIGH] [TEST-MISSING-CRITICAL] No tests for critical circuit breaker behavior change

Why this is a problem: This change adds a critical condition that allows failureThreshold = 0 to disable the circuit breaker entirely. This is a behavioral change to production code with no test coverage. Per CLAUDE.md, the project uses Vitest and has coverage thresholds, but there are no existing tests for circuit-breaker.ts at all.

Suggested fix: Add unit tests covering these cases:

// tests/unit/circuit-breaker.test.ts
describe('circuit breaker with threshold = 0', () => {
  it('should never open circuit when threshold is 0', async () => {
    // Set failureThreshold = 0
    // Record 100 failures
    // Verify circuit remains closed
  });
});

describe('circuit breaker with threshold > 100', () => {
  it('should function normally with high threshold values', async () => {
    // Set failureThreshold = 150
    // Record 149 failures - circuit should stay closed
    // Record 150th failure - circuit should open
  });
});

Without tests, we cannot verify this critical behavior works correctly across application restarts, Redis failures, or concurrent requests.

[github-actions]

Code Review Summary

This PR successfully implements flexible failure threshold configuration, allowing values of 0 (disabled) and above 100. However, critical i18n violations and missing test coverage require attention before merge.

PR Size: XS

• Lines changed: 68 (61 additions, 7 deletions)
• Files changed: 3
• Assessment: Appropriate size for this feature addition

Issues Found

Category	Critical	High	Medium	Low
Logic/Bugs	0	0	0	0
Security	0	0	0	0
Error Handling	0	0	0	0
Types	0	0	0	0
Comments/Docs	0	0	1	0
Tests	0	1	0	0
Standards	0	2	0	0

High Priority Issues (Must Fix)

1. [STANDARD-VIOLATION] Hardcoded Chinese text in confirmation dialog (provider-form.tsx:1701, 1722)

   • The entire codebase uses t() function for i18n (5 locales configured)
   • New dialog has hardcoded Chinese text, breaking non-Chinese locales
   • See inline comments for complete i18n implementation

2. [TEST-MISSING-CRITICAL] No test coverage for circuit breaker behavior (circuit-breaker.ts:248)

   • Core logic change (threshold=0 disables circuit breaker) has no tests
   • No existing test file for circuit-breaker.ts despite project using Vitest
   • Cannot verify correct behavior across restarts, Redis failures, or concurrent requests
   • See inline comment for test cases needed

Medium Priority Issues (Should Fix)

3. [COMMENT-INCOMPLETE] Misleading UI message for threshold > 100 (provider-form.tsx:1712)
   • Message implies >100 has special behavior, but it's just a normal high threshold
   • Creates asymmetry with threshold=0 messaging (which truly has special behavior)
   • See inline comment for suggested clarification

Review Coverage

• Logic and correctness - Clean
• Security (OWASP Top 10) - Clean
• Error handling - Clean
• Type safety - Clean
• Documentation accuracy - Issue found (Medium)
• Test coverage - Issue found (High)
• Code clarity - Clean
• I18n compliance - Issues found (High)

Positive Aspects

• Core logic implementation is sound (threshold=0 check in circuit-breaker.ts)
• Validation schema updated correctly to allow new ranges
• User confirmation dialog is a good UX pattern for potentially dangerous settings
• Function extraction (performSubmit) improves code organization

---

Automated review by Claude AI

[ding113]

按照项目的风格，AlertDialog里的内容属于前端文案范围，应该有 i18n 支持。
建议参考 #498 (comment) 完成 i18n 字符串添加。