Skip to content

[Follow-up] Move model-ab retry to per-(model,set) arm granularity in the #1097 comparator #1954

Open

Description

@don-petry

Context

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 into model-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.

Why deferred from #1952

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.

References

Activity

  1. github-actions commented on Sep 26, 2026

    @github-actions
    Contributor

    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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions