You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Follow-up] Move model-ab retry to per-(model,set) arm granularity in the #1097 comparator #1954
Split out from PR #1952 (issue #1950). CodeRabbit raised a valid functional-correctness concern about the model-ab-dispatch.sh retry loop, and the maintainer deliberately deferred the deep fix to keep #1952 scoped. This issue tracks that follow-up.
Problem
scripts/evals/model-ab.sh runs a candidate/incumbent pair per requested set and emits a single infra verdict with exit 2 when any set is unscored — even if another set/arm already scored. scripts/evals/model-ab-dispatch.sh then retries the whole command on exit 2, which can re-run arms that already produced a scored number. That violates the "a scored arm is never re-run" requirement.
The dispatcher-level mitigation already in #1952 (retry only when the exit-2 output is valid evidence JSON, i.e. a genuine transient infra verdict, not a deterministic hard error) narrows when the whole-command retry fires, but does not make retries per-arm — a valid-infra exit 2 that also carries an already-scored arm can still re-run that scored arm.
Proposed fix
Move retry handling intomodel-ab.sh so each unscored (model, set) arm retries independently, tracking a per-arm ledger so a scored arm is never re-run. Then remove the dispatcher's whole-command retry loop.
This requires refactoring the #1097 comparator's core arm loop (run_arm / the per-set scoring in scripts/evals/model-ab.sh) to expose per-arm exit status plus a "scored arms are never rerun" ledger, and rewiring the dispatcher around it. That is a heavy-lift change to a separately-tested component #1952 does not otherwise touch; rushing it risks regressing the held-out immutability and scoring guarantees the comparator already enforces.
Thanks for the thorough write-up and for cleanly splitting this out from #1952 — having the full context, references, and deferred-rationale in one place makes this much easier to pick up. To help anchor the per-arm ledger design and ensure there's a solid regression test: is there a known input sequence (specific model pair, set count, and infra-transient failure pattern) that reliably triggers the scored-arm re-run today, or is this currently a theoretical path that the #1952 dispatcher mitigation narrows but doesn't fully close?
Activity
github-actions commentedon Sep 26, 2026
Thanks for the thorough write-up and for cleanly splitting this out from #1952 — having the full context, references, and deferred-rationale in one place makes this much easier to pick up. To help anchor the per-arm ledger design and ensure there's a solid regression test: is there a known input sequence (specific model pair, set count, and infra-transient failure pattern) that reliably triggers the scored-arm re-run today, or is this currently a theoretical path that the #1952 dispatcher mitigation narrows but doesn't fully close?