test(e2e): pin live weight-edit re-takes effect on dispatch (#196 L1)

[moonming]

What

Closes the L1 gap (config edit → observable behavior change). The sibling weighted-routing-distribution-e2e pins that a weighted model's initial weights are honored. This pins that a live edit to those weights propagates and the weighted scheduler rebuilds — a scheduler that cached its weight-wheel on first dispatch and ignored config updates would silently keep serving the old split.

How (deterministic, no statistics)

weight 0 = excluded (per routing-strategies-e2e "weighted picks the positive-weight target"):

1. Create wr-edit-virtual weighted [wr-edit-a: 100, wr-edit-b: 0] → assert all BATCH dispatches hit A.
2. PUT /admin/v1/models/:id inverting to [0, 100].
3. Propagation signal: a virtual probe returning "served by B" — impossible under the old [100,0] config, so it proves the edit is live and the scheduler rebuilt before counting.
4. Assert all BATCH dispatches now hit B.

If the scheduler never rebuilds on a config edit (the regression this targets), step 3's waitConfigPropagation times out — surfacing it loudly rather than passing silently.

Note on a possible real finding

If CI shows step 3 timing out, that's a real DP bug (weighted scheduler doesn't rebuild on weight edit) — I'll file it + hold this test, not weaken the assertion. Expected: the DP rebuilds on the etcd-watch snapshot swap (the same path every config-change test relies on), so it should pass.

Verification

tsc --noEmit clean for this file (borrowed node_modules; fresh worktree). Authoritative run is CI's isolated e2e job (etcd + built DP + in-process mock upstreams — no shared-stack contention).

Refs #196 L1, #127 L1.

[coderabbitai]

Warning

Review limit reached

@moonming, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 8 minutes and 3 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Free

Run ID: 7a603f8b-22a6-404b-9b39-b12d579b7c2f

📥 Commits

Reviewing files that changed from the base of the PR and between b6a8bd2 and 0053886.

📒 Files selected for processing (1)

• tests/e2e/src/cases/weighted-routing-edit-e2e.test.ts

---

Note

🎁 Summarized by CodeRabbit Free

Your organization has reached its limit of developer seats under the Pro Plan. For new users, CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please add seats to your subscription by visiting https://app.coderabbit.ai/login.If you believe this is a mistake and have available seats, please assign one to the pull request author through the subscription management page using the link above.

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

[moonming]

Independent audit (CLAUDE.md §8) — CLEAR

A cold third-party agent reviewed against the actual DP scheduler source. No HIGH/MEDIUM.

• Weight-0 = exact exclusion — weighted_pick (routing.rs) uses strict pick < acc; a 0-weight target is unreachable. Unit-pinned (weighted_pick_zero_weight_target_in_middle_is_never_picked, 2000 trials) + the sibling routing-strategies test. So "all A"/"all B" can't flake on selection.
• No fall-forward to the 0-weight target — the dispatch loop only advances on a retryable failure; the mock returns 200, which stops dispatch before the in-list 0-weight fallback is contacted. Single dispatch/request, bDelta==0/aDelta==0 guaranteed.
• PUT body schema-valid + can't 4xx — update_model requires only display_name; weight: minimum 0; same shape as the create that already validated; assert_unique_name(..., Some(id)) excludes self. Revision is bumped → etcd watch fires.
• Propagation signal sound — "served by B" is provably impossible under the old [100,0] config; no partial-snapshot window yields it early; the wait fully gates phase 2; baselines snapshotted after the probe so it isn't counted.
• Catches the regression loudly — a scheduler that ignored the edit → probe stays A → waitConfigPropagation throws (30s). No silent-pass path.
• Cleanup + isolation — upstreams + app closed; unique etcd prefix/ports/admin-key/display-names/caller-key → safe under maxForks=2 alongside the sibling.

Two LOWs (readiness gate + error-swallowing) are established harness idioms, no change. Verdict: safe to merge.