[github-actions]

What this PR does

My large OMENative components rewrite status.components..traffic and re-enqueue their HTTPRoute every few seconds as pods blip Pending between reconciles — what does ome.controller.coordination.trafficWeightDeadbandPercent do, what is its default, and which changes does the band never suppress?

Why we need it

Source change: ome-projects/ome@eb2686d

From commit 145 (#804, InferenceService controller overhaul), whose patch (read today) introduced TrafficWithinDeadband and the trafficWeightDeadbandPercent config end to end (definition and gate at patch hunks 60150-60178 and 52642, tests at 60481-60535). Current code verified today: charts/ome-resources/values.yaml:452-462 — ome.controller.coordination.trafficWeightDeadbandPercent, chart default 0 (band off, 'write on any diff — the prior behavior'), rendered into the coordination entry of the inferenceservice-config ConfigMap by templates/ome-controller/configmap.yaml:77-81; pkg/controller/v1beta1/controllerconfig/configmap.go:511-527 — the per-revision hysteresis band applied to the pod-proportional traffic writer: a recomputed weight set whose every per-revision percent moves by strictly less than the band from what Status.Components..Traffic already holds is treated as pod-count jitter, and the status write plus the HTTPRoute re-enqueue it triggers is suppressed; intentionally no in-code default. It is hot configuration: inferenceservice/controller.go:1060-1081 loads the coordination config through the config cache 'on every pass' (so it is correctly absent from configure-the-controller.md's needs-a-restart list at :175-182). The gate: coordination/reconciler.go:575-584 writes traffic only when TrafficDiffersMeaningfully AND NOT TrafficWithinDeadband; coordination/traffic.go:241-272 pins what the band never suppresses — a changed revision set, a LatestRevision flip, and terminal/boundary convergence (any revision moving to exactly 0 or 100 is always written, so a band larger than the final canary step cannot stick traffic at 95/5) — and that a sustained ratio change always converges because the band is per-revision, not cumulative. Tests in today's checkout: coordination/traffic_test.go:249-360 (blip suppressed; sustained change converges; zero/negative disables; revision-set change, terminal convergence and LatestRevision flip never suppressed). Docs gap verified today: a repo-wide grep for trafficWeightDeadbandPercent and deadband under src/lib/content matches nothing (rollout-groups.md:109 documents only the sibling field defaultRatioTolerancePercent); configure-the-controller.md has a tuning section for every neighboring pacing knob — scale batches (:218), prefill-decode roll (:287), canary re-checks (:323) — but nothing for the coordination entry's band, and canary-progression.md's Traffic weight in status section documents the written weights with no note that a configured band can hold sub-band updates. One independent concern: one operator tunable with one suppression rule and its never-suppressed exceptions, from the commit that added it, as a section on the page that owns ome.controller tunables. configure-the-controller.md is also listed by the pending rollouts item rollout-plan-size-cap (a different concern: an admission cap) — the workflow selects one per available file and queues the rest; do not combine. Distinct from merged #185 (scale-down pacing on the same page) and #202/#199 (metric series).

Scope: operations / traffic-weight-deadband. Other concerns are deferred.

How to test

• Passed the documentation path and size guard (under 1000 added plus deleted lines; no file-count limit).
• Passed an independent accuracy and single-concern review.
• Passed git diff --check and website content/link tests, type checks, lint and production build.

Checklist

• Every commit is signed off (git commit -s)
• pnpm lint && pnpm check && pnpm test && pnpm build passes (run by the publisher on an isolated copy)

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 300c824b-94d7-4ee3-a11b-d56b83b3f446

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

[github-actions]

Documentation maintenance: working. Unsuccessful content rounds: 0/3. Operational attempts: 1/3.

Head: 87f8a392711eee6c9eecd8701648dbe5c57ffdfe; reviewed main: d8efccf291eb991c7efcddcd4979f8f01c1557c4.

Repair/validation in progress; no merge authorization implied.

Workflow evidence

Human review threads and CODEOWNER approval remain under repository policy.