docs(features): add failover page#236
Conversation
📝 WalkthroughWalkthroughDocumentation was expanded to cover GoModel's failover functionality. A new navigation entry was added to the docs configuration, and a comprehensive documentation page was created explaining failover setup, modes (manual and auto), configuration parameters, triggered scenarios, and supported endpoints. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/features/failover.mdx`:
- Line 25: The phrase "ordered JSON map" is misleading; update the sentence
referencing `config/fallback.json` in docs/features/failover.mdx to state that
ordering applies to each model's candidate list (the arrays of fallbacks) not
the top-level JSON object keys—e.g., reword to "candidate lists (arrays) in each
model's entry are ordered; top-level keys are not." Also add a brief one-line
clarifier pointing readers to the model entry array (the candidate list) as the
order-sensitive structure.
- Around line 54-57: Update the wording in the Auto mode description so it
reflects that category matching is a hard filter rather than a soft preference:
change the sentence that currently reads “prefers models with the same request
category” to indicate candidates that do not support the required category are
excluded (e.g., “requires matching request category” or “filters out models that
don’t support the request category”) and keep the rest of the sentence about
ranking and family preference intact; target the paragraph that begins “Auto
mode keeps any manual candidates first…” and the clause referencing “prefers
models with the same request category.”
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 09503365-b96b-458b-a5dc-13e1901d0c25
📒 Files selected for processing (2)
docs/docs.jsondocs/features/failover.mdx
| Auto mode keeps any manual candidates first, then appends up to five extra | ||
| candidates from the current model registry. It prefers models with the same | ||
| request category, similar rankings, overlapping capabilities, and the same | ||
| family when possible. |
There was a problem hiding this comment.
Auto-mode category behavior is documented as a preference, but it is a filter.
Lines 55-56 say auto mode “prefers models with the same request category.” In implementation, candidates that do not support the required category are excluded before ranking, so this is effectively mandatory.
Proposed doc tweak
-Auto mode keeps any manual candidates first, then appends up to five extra
-candidates from the current model registry. It prefers models with the same
-request category, similar rankings, overlapping capabilities, and the same
-family when possible.
+Auto mode keeps any manual candidates first, then appends up to five extra
+candidates from the current model registry. Extra candidates must support the
+same request category, then are ranked by similarity in rankings, overlapping
+capabilities, and family preference when possible.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Auto mode keeps any manual candidates first, then appends up to five extra | |
| candidates from the current model registry. It prefers models with the same | |
| request category, similar rankings, overlapping capabilities, and the same | |
| family when possible. | |
| Auto mode keeps any manual candidates first, then appends up to five extra | |
| candidates from the current model registry. Extra candidates must support the | |
| same request category, then are ranked by similarity in rankings, overlapping | |
| capabilities, and family preference when possible. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/features/failover.mdx` around lines 54 - 57, Update the wording in the
Auto mode description so it reflects that category matching is a hard filter
rather than a soft preference: change the sentence that currently reads “prefers
models with the same request category” to indicate candidates that do not
support the required category are excluded (e.g., “requires matching request
category” or “filters out models that don’t support the request category”) and
keep the rest of the sentence about ranking and family preference intact; target
the paragraph that begins “Auto mode keeps any manual candidates first…” and the
clause referencing “prefers models with the same request category.”
There was a problem hiding this comment.
♻️ Duplicate comments (1)
docs/features/failover.mdx (1)
57-60:⚠️ Potential issue | 🟡 MinorAuto-mode category matching is still described as a preference, not a requirement.
On Line 58, “prefers models with the same request category” is misleading. Based on
internal/fallback/resolver.go:69-97, category is used as a hard eligibility filter for auto candidates, then remaining candidates are ranked.Suggested doc fix
Auto mode keeps any manual candidates first, then appends up to five extra -candidates from the current model registry. It prefers models with the same -request category, similar rankings, overlapping capabilities, and the same -family when possible. +candidates from the current model registry. Extra candidates must support the +same request category, then are ranked by similarity in rankings, overlapping +capabilities, and family preference when possible.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/features/failover.mdx` around lines 57 - 60, Update the docs to state that auto mode requires matching request category as a hard eligibility filter rather than merely preferring it: change the phrasing “prefers models with the same request category” to something like “requires models to match the request category (used as an eligibility filter), then ranks remaining candidates.” Reference the eligibility logic in resolver.go (the auto-candidate eligibility block at lines ~69-97) that applies the category filter before ranking so the doc matches the implementation.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@docs/features/failover.mdx`:
- Around line 57-60: Update the docs to state that auto mode requires matching
request category as a hard eligibility filter rather than merely preferring it:
change the phrasing “prefers models with the same request category” to something
like “requires models to match the request category (used as an eligibility
filter), then ranks remaining candidates.” Reference the eligibility logic in
resolver.go (the auto-candidate eligibility block at lines ~69-97) that applies
the category filter before ranking so the doc matches the implementation.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 4676b782-47d7-4788-8402-960dec65068f
📒 Files selected for processing (1)
docs/features/failover.mdx
Summary
Validation
mint validateSummary by CodeRabbit