Skip to content

feat: canary models, adapters, and policies separately with automatic rollback - #34

Merged
github-actions[bot] merged 1 commit into
mainfrom
feat/21-canary-tracks
Oct 3, 2026
Merged

github-actions[bot] merged 1 commit into
mainfrom
feat/21-canary-tracks

Conversation

@Yash-Chindam

Copy link
Copy Markdown
Owner

Seventh PR closing gaps between the design spec and the implementation.

Gap this closes

§13 "Canary models, adapters and router policies separately" and the design target "Automatic rollback after failed readiness or canary criteria". Previously there was one combined plan whose rollback triggers were four strings, and nothing evaluated them.

Behaviour change

A staging adapter used to compete with the production one on measured quality delta, so a staged adapter with the larger gain took 100% of traffic. It now takes canary_traffic_percent (default 10). A Router built without a monitor gives a staged adapter no traffic at all.

What changed

  • canary.py: one CanaryPlan per canary on its own track (model, adapter, policy), with criteria derived from the catalog: the strictest tier latency objective among the models served, and their benchmarked quality less a tolerance.
  • evaluate(): failed readiness rolls back with no sample; after 50 requests, error rate, p95, or quality over the line rolls back. Error rate and latency are compared with the stable arm, so a shared outage does not roll back an innocent change.
  • Adapter track in the gateway: deterministic traffic split by tenant and prompt, automatic suspension on failure, and no caching of canary responses.
  • GET /v1/registry/canaries, plus router_canary_requests_total and router_canary_rollbacks_total.
  • python -m llm_router.canary prints the plans; with --plan and --observation it exits 0/2/3 for promote/hold/rollback. CD now renders all plans instead of one.
  • RoutePolicy gains previous_version, canary settings, and per-tier latency objectives. serving.canary_config is removed in favour of the per-track plans.

Not done

  • Model and policy rollback is decided but not actuated. The command returns the verdict and the rollback target; no rollout controller calls it yet. That wiring belongs with the deployment topology work.
  • Canary state is per gateway replica and is lost on restart, so a restarted replica re-admits a suspended adapter until it fails its sample again.
  • The live quality signal is structured-output validity only, as elsewhere.

Test plan

  • 35 new tests, including a failing staged adapter being suspended after exactly its 50-request sample with production serving thereafter, and an outage shared by both arms not triggering a rollback
  • ruff format --check ., ruff check ., mypy clean
  • pytest tests/unit tests/integration: 314 passed, coverage 98%
  • Playwright end-to-end suite: 9 passed locally

🤖 Generated with Claude Code

… rollback

Section 13 canaries models, adapters, and router policies separately, and
the design targets require rollback to be automatic once readiness or
canary criteria fail. There was one combined plan that listed rollback
triggers as text, and nothing acted on them. A staged adapter with the
larger measured gain simply took all of the traffic.

Each track now has its own plan naming what it rolls back to, and one
rule decides them all: failed readiness rolls back at once; error rate,
latency, and quality roll back once enough requests have been seen.
Error rate and latency only count against a canary when the stable
baseline does not share the problem, so an engine outage that degrades
both arms is not blamed on the change.

The adapter track runs inside the gateway. A staged adapter is offered a
fixed share of eligible requests, bucketed by tenant and prompt so a
retry cannot flip between adapters, and is suspended the moment it fails.
Its responses are never cached, so nothing it produced outlives a
rollback.

Model and policy canaries are rollouts, so the plan is evaluated through
the same rule by a command whose exit code says promote, hold, or roll
back. Promotion is never automatic on any track.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions github-actions Bot added documentation Improvements or additions to documentation area/api area/tests area/ci-cd labels Oct 3, 2026
@github-actions
github-actions Bot merged commit 2f64b58 into main Oct 3, 2026
6 checks passed
@github-actions
github-actions Bot deleted the feat/21-canary-tracks branch October 3, 2026 14:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/api area/ci-cd area/tests documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant