feat: endpoint optional

[thushan]

This is an old PR that allows users to simplify their endpoint configurations by making health_check_url and model_url optional, with intelligent profile-based defaults.

This means before this change:

  endpoints:
    - url: "http://localhost:11434"
      type: "ollama"
      health_check_url: "/"      # REQUIRED
      model_url: "/api/tags"   # REQUIRED

After this change:

  # Option 1: Existing configs still work EXACTLY the same
  endpoints:
    - url: "http://localhost:11434"
      type: "ollama"
      health_check_url: "/"      # Still respected if provided
      model_url: "/api/tags"   # Still respected if provided

  # Option 2: Users can NOW simplify (but don't have to)
  endpoints:
    - url: "http://localhost:11434"
      type: "ollama"
      # health_check_url and model_url auto-detected

Docs also updated.

Summary by CodeRabbit

• Documentation

  • Expanded health checking and URL configuration documentation with detailed examples and platform-specific profile defaults.
  • Added guidance on relative and absolute path handling, including base path preservation behaviour.
  • Included check interval and timeout recommendations for different endpoint configurations.

• New Features

  • Health check and model URLs are now optional, defaulting based on endpoint type and configured profiles.

[coderabbitai]

Walkthrough

Reworks documentation for health check and model URL configuration to introduce optional fields with profile-based defaults. Implements code changes to resolve URLs using profile-aware defaults when fields are empty, includes validation tests for multiple endpoint types, and demonstrates URL composition patterns.

Changes

Cohort / File(s)	Summary
Health Check Configuration Documentation docs/content/concepts/health-checking.md	Reorganises health check configuration guide to introduce optional health_check_url with profile defaults. Replaces "Health Check URLs by Platform" with detailed "Profile Defaults" table, adds "Check Intervals" and "Check Timeouts" guidance, includes "Leverage Profile Defaults" in best practices, and expands model discovery health checks with examples for both default and custom URLs.
Configuration Examples Documentation docs/content/configuration/examples.md, docs/content/configuration/overview.md, docs/content/configuration/reference.md	Adds new "URL Configuration Examples" section demonstrating discovery endpoint patterns with minimal defaults, base path handling, and external health/model endpoints. Updates optional fields tables to reflect profile-specific defaults. Expands Static Endpoints documentation with detailed "URL Configuration" subsection, profile defaults table, and examples showing relative vs absolute URL handling and base-path preservation.
URL Defaults Resolution Implementation internal/adapter/discovery/repository.go	Introduces resolveURLDefaults() and applyProfileDefaults() helper functions to resolve health check and model URLs from profile-based defaults when fields are empty. Updates LoadFromConfig() to derive healthCheckPath and modelPath via new helpers instead of directly using config values, with fallback to universal defaults.
URL Defaults Resolution Tests internal/adapter/discovery/repository_test.go	Adds comprehensive test suite validating endpoint configuration handling when URLs are empty across multiple types (ollama, auto, lm-studio). Tests profile-driven fallback behaviour, default URL resolution for each endpoint type, base URL and path prefix preservation, and multiple endpoint configurations.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• fix: Alternative method of resolving profile paths #90: Overlapping code-level changes to discovery URL resolution with profile-aware path handling and defaults logic.

🚥 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
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'feat: endpoint optional' directly summarises the main change—making endpoint configuration fields optional with intelligent defaults.

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

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feature/endpoint-optionals

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@docs/content/concepts/health-checking.md`:
- Around line 94-104: The table uses "OpenAI-compatible" but other
docs/reference use the profile key "openai" (and there may also be
"openai-compatible"); update the defaults table so it explicitly lists both
profile keys ("openai" and "openai-compatible" / "openai-compatible") or
separates them if their defaults differ, and ensure the health_check_url and
model_url values match the actual profile YAMLs and the reference document;
audit the profile YAMLs for the exact identifiers ("openai",
"openai-compatible") and sync the table entries and any surrounding text to use
the canonical profile names and correct default paths.

🧹 Nitpick comments (1)

docs/content/configuration/reference.md (1)

247-280: Comprehensive URL configuration section with clear examples.

The profile defaults table, relative/absolute URL explanations, and base-path preservation note are accurate and well-presented. The examples match the implementation in ResolveURLPath.

One observation: the table covers 7 types but the project also supports openai-compatible, lemonade, and litellm profiles (per the project's profile directory). Consider adding these for completeness, or noting that unlisted types fall through to the "auto (or unknown)" defaults.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Minor inconsistency in profile defaults table across documentation pages.

This table lists "OpenAI-compatible" (line 103), whilst reference.md lists openai (line 260). From the learnings, both openai and openai-compatible are distinct profile types. If they share the same defaults, consider listing both here for completeness. If they differ, each table is only showing a subset of the supported types, which could confuse users.

#!/bin/bash
# Check available profile YAML files to see which types exist
echo "=== Profile YAML files ==="
fd -e yaml . --full-path --glob '**/profiles/**'

echo ""
echo "=== Health check paths defined in profiles ==="
rg -n 'health_check' --type=yaml -C2 -g '**/profiles/**'

echo ""
echo "=== Model discovery paths defined in profiles ==="
rg -n 'model_discovery_path\|ModelDiscoveryPath' --type=yaml --type=go -C2

🤖 Prompt for AI Agents

In `@docs/content/concepts/health-checking.md` around lines 94 - 104, The table
uses "OpenAI-compatible" but other docs/reference use the profile key "openai"
(and there may also be "openai-compatible"); update the defaults table so it
explicitly lists both profile keys ("openai" and "openai-compatible" /
"openai-compatible") or separates them if their defaults differ, and ensure the
health_check_url and model_url values match the actual profile YAMLs and the
reference document; audit the profile YAMLs for the exact identifiers ("openai",
"openai-compatible") and sync the table entries and any surrounding text to use
the canonical profile names and correct default paths.