Skip to content

feat: a fallback chain can be configured through the API, not only the CLI - #144

Open
thedancingdeveloper wants to merge 1 commit into
mainfrom
feat/configure-fallbacks-through-the-api
Open

feat: a fallback chain can be configured through the API, not only the CLI#144
thedancingdeveloper wants to merge 1 commit into
mainfrom
feat/configure-fallbacks-through-the-api

Conversation

@thedancingdeveloper

Copy link
Copy Markdown
Contributor

Follow-up to #141, found while repointing Node B's models.

#141 added fallback chains to ModelClient, the CLI (--implementer a,b,c)
and the stored role map. It did not add them to RoleRoute, which is the
only way to configure a deployed harness:

$ curl .../openapi.json | jq '.components.schemas.RoleRoute.properties|keys'
["endpoint","model","provider"]

So the models an operator chose could be set on a laptop and not on the machine
that runs the work. A feature that cannot be configured where it is used is not
shipped.

Change

  • models: the chain, in preference order.
  • model: still there, still the preferred route, filled in from models[0]
    when omitted — so every existing stored map, client and reader that knows
    only model is untouched.
  • Both may be given, and are checked against each other. A route where they
    disagree behaves differently depending on which field a reader consults, so
    it is refused with the mismatch named.

Four tests: the chain round-trips schema → stored map → Chain; a single
model is unchanged; and both refusal cases.

Suite, ruff and mypy . green.

…e CLI

Chains shipped in the CLI and in the stored role map, and `RoleRoute` -- the
only way to configure a deployed pod -- could not express one. Found while
repointing Node B: the models an operator had chosen could be set locally and
not on the machine that runs the work, which makes the feature unshipped where
it matters.

`models` names the chain in preference order; `model` stays the preferred one
and is filled in from the first when omitted, so every existing map, client and
reader that knows only `model` is unaffected. Giving both is allowed and
checked: a route whose two fields contradict each other behaves differently
depending on which one a reader consults, so it is refused with the mismatch
named rather than silently resolved.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant