fix(server): warn on duplicate target model ids

[elyasmnvidian]

Two targets accidentally share one model id on one llm client:

[llm_clients.primary]
format = "openai_chat"
base_url = "https://api.openai.com/v1"

[targets.priority]
id = "gpt-4o"
llm_client = "primary"

[targets.flex]
id = "gpt-4o"
llm_client = "primary"

[routes.priority]
id = "switchyard/priority"
type = "passthrough"
target = "priority"

[routes.flex]
id = "switchyard/flex"
type = "passthrough"
target = "flex"

An llm client keeps its models in a map keyed by id, so two targets with the same id on one client end up as one entry: the client keeps one target and drops the other. Both routes still start, and nothing reports the dropped target:

$ switchyard-server --config deploy.toml --dry-run
server OK: switchyard/flex, switchyard/priority     # one target was dropped, no message

The fix

switchyard-server now checks each (llm client, model id) pair while it reads the config. When two targets on one client reuse an id, it logs a warning that names the target, the id, and the client, then keeps starting:

$ switchyard-server --config deploy.toml --dry-run
WARN switchyard_server::config: target priority reuses model id gpt-4o on llm client primary; only one target per id is kept and the other is dropped. Give each target a unique model id, or point both routes at one target.
server OK: switchyard/flex, switchyard/priority

The same id on two different llm clients is fine and stays quiet — each client keeps its own model, so nothing is dropped. That is how you serve one model through two providers or two API keys.

What it does and does not do

The warning makes the dropped target visible at startup instead of silent. It does not stop the server: both routes still start, and the surviving target is what both serve.

One case to know: if the two targets differ only by extra_body (say two service_tier values), the client still keeps one and drops the other's extra_body. The check works from a set of (llm client, model id) pairs, so it can't compare the two targets — it warns the same for a harmless duplicate and for one that drops real config. Read the warning as "a target was dropped; make sure that is what you meant." To serve two tiers of one model, give each its own llm client (same base_url, different client name).

Evidence

$ switchyard-server --config deploy.toml --dry-run          # two targets, same id on one client
WARN ...: target priority reuses model id gpt-4o on llm client primary; only one target per id is kept and the other is dropped. ...
server OK: switchyard/flex, switchyard/priority             # exit 0, both routes start

$ switchyard-server --config deploy-fixed.toml --dry-run     # flex.id = gpt-4o-mini
server OK: switchyard/flex, switchyard/priority              # exit 0, no warning

No perf table — this change adds a startup warning, it does not change speed.

Compatibility

No breaking change: every config that started before still starts. A config with two same-id targets on one client now prints a warning where it used to say nothing.

How tested

cargo test -p switchyard-server passes (23 config tests, 17 server tests). Two config tests cover the behavior:

• accepts_duplicate_target_model_ids_on_one_client — two targets, same id and client; the build warns and still succeeds, and both routes resolve.
• accepts_same_model_id_on_different_llm_clients — same id on two clients; the build succeeds with no warning.

cargo clippy -p switchyard-server --all-targets -- -D warnings and cargo fmt --all --check are clean.

Reproducer:

cargo build -p switchyard-server
./target/debug/switchyard-server --config deploy.toml --dry-run     # then deploy-fixed.toml

[coderabbitai]

Walkthrough

Changes

ServerConfig::build now validates target fields and rejects duplicate (llm_client, target.id) pairs. Tests cover rejection on one client and acceptance across different clients.

Target configuration validation

Layer / File(s)	Summary
Centralized target validation crates/switchyard-server/src/config.rs	Target name and model ID validation moved into ServerConfig::build, which also detects duplicate client-target pairs before client construction.
Duplicate and cross-client coverage crates/switchyard-server/src/config.rs	Tests verify precise duplicate errors and allow identical model IDs across different LLM clients.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Poem

I’m a rabbit checking targets bright,
No duplicate models sneak from sight.
One client, one pair, kept neat,
Across clients, repeats are sweet.
Hop, hop—tests make configs complete!

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title identifies duplicate target model IDs in the server, which is the main change, although the implementation rejects duplicates rather than warns.

---

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