fix(server): stop silently dropping 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"
extra_body = { service_tier = "priority" }

[targets.flex]
id = "gpt-4o"
llm_client = "primary"
extra_body = { service_tier = "flex" }

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

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

The server stores each client's models by id, so it keeps one target and drops the other. Both routes start, but one service_tier is gone and nothing says so — every request to switchyard/flex now sends priority:

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

The fix

switchyard-server now checks the targets on each llm client before it starts.

• Same id, different extra_body — dropping one target loses real config, so the server won't start. It prints an error naming both targets and how to fix it.
• Same id, otherwise the same — dropping one loses nothing, so the server warns and serves both routes (one model under two route names, e.g. a benchmark A/B).
• Same id on two different llm clients — each client keeps its own model, so nothing is dropped. This still works with no warning; it's how you serve one model through two providers or two API keys.

Evidence

The broken config above now stops at startup, and a fixed config still starts:

$ switchyard-server --config deploy.toml --dry-run
invalid server config deploy.toml: targets flex and priority both use model id gpt-4o on llm client primary but set different extra_body; only one would take effect. Give them different model ids, or point both routes at one target.

$ switchyard-server --config deploy-fixed.toml --dry-run     # distinct ids, or both routes on one target
server OK: switchyard/priority, switchyard/flex

No perf table — this change is about which configs start, not speed.

Compatibility

A config with two same-id targets and different extra_body on one client used to start and drop one silently; it now stops at startup. To fix it, give the targets different ids, or point both routes at one target. The same id across two clients, and same-id targets that are otherwise the same, keep starting as before.

Honest trade-off: two same-id targets that are otherwise the same still start with a warning, so a typo that repeats a model id you already serve is reported but not blocked. Rejecting every same-client duplicate was the alternative — set aside so a deliberate "one model, two route names" setup keeps working without edits. The deeper limit: the client stores models by id alone, so it can't hold two extra_body values under one id — serving two service tiers on one key isn't supported yet, and this change makes that stop loudly instead of dropping one silently.

How tested

cargo test -p switchyard-server passes. Three config tests pin the behavior:

• rejects_duplicate_target_ids_with_different_extra_body — same id and client, different extra_body; the server stops. Fails on the old code, so it pins the fix.
• accepts_duplicate_target_model_ids_on_one_client — two same-id targets, otherwise the same; the server warns and both routes still resolve.
• accepts_same_model_id_on_different_llm_clients — same id on two clients; starts 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 clearly and concisely describes preventing duplicate target model IDs from being silently dropped, matching the pull request's primary change.

---

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

[grahamking]

Do you want HashSet instead?

[ryan-lempka]

Anthropic models love the BTreeMap. Opus 4.8 tried using one for me earlier where it did not seem to make sense.

[elyasmnvidian]

I changed to HashMap

[grahamking]

I meant Set. Don't you only need to know if it exists already or not? i.e you only need Key, not Key/Value.

[grahamking]

The HashMap<(&str, &str), (&str, &TargetConfig)> with target four way is awkward. Can we clean that up?

Ideally we'd have a single HashSet that says whether we've seen this before or not.