Skip to content

docs(features): add failover page#236

Merged
SantiagoDePolonia merged 2 commits intomainfrom
docs/failover
Apr 16, 2026
Merged

docs(features): add failover page#236
SantiagoDePolonia merged 2 commits intomainfrom
docs/failover

Conversation

@SantiagoDePolonia
Copy link
Copy Markdown
Contributor

@SantiagoDePolonia SantiagoDePolonia commented Apr 16, 2026

Summary

  • add a new Features page for failover
  • explain how to configure manual mode
  • document that auto mode is experimental and summarize how it selects candidates
  • add the page to the Mintlify Features navigation

Validation

  • mint validate

Summary by CodeRabbit

  • Documentation
    • Added failover configuration documentation covering manual and auto failover modes with setup instructions.

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai bot commented Apr 16, 2026

📝 Walkthrough

Walkthrough

Documentation 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

Cohort / File(s) Summary
Documentation Navigation
docs/docs.json
Added "features/failover" entry to the Features section of the navigation configuration.
Failover Documentation
docs/features/failover.mdx
New page documenting GoModel failover configuration, including manual mode with manual_rules_path, auto mode (experimental) with candidate ranking, failover trigger conditions (5xx/429 errors, model unavailability), and supported endpoints (/v1/chat/completions, /v1/responses).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A failover path so carefully laid,
When models stumble, backups got your aid!
With docs so clear, both manual and auto flows,
The rabbits rejoice as the knowledge grows! 🎉

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'docs(features): add failover page' directly and clearly summarizes the main change: adding documentation for the failover feature to the Features section.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch docs/failover

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.

@mintlify
Copy link
Copy Markdown

mintlify bot commented Apr 16, 2026

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
gomodel 🟢 Ready View Preview Apr 16, 2026, 12:28 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

Copy link
Copy Markdown
Contributor

@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: 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

📥 Commits

Reviewing files that changed from the base of the PR and between 05b28a4 and f67e965.

📒 Files selected for processing (2)
  • docs/docs.json
  • docs/features/failover.mdx

Comment thread docs/features/failover.mdx Outdated
Comment on lines +54 to +57
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.
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.

⚠️ Potential issue | 🟡 Minor

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.

Suggested change
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.”

Copy link
Copy Markdown
Contributor

@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.

♻️ Duplicate comments (1)
docs/features/failover.mdx (1)

57-60: ⚠️ Potential issue | 🟡 Minor

Auto-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

📥 Commits

Reviewing files that changed from the base of the PR and between f67e965 and 205b311.

📒 Files selected for processing (1)
  • docs/features/failover.mdx

@SantiagoDePolonia SantiagoDePolonia merged commit aa0da4c into main Apr 16, 2026
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant