mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-07-26 09:52:11 +03:00
c6d8acde32
POST /api/combos and PUT /api/combos/[id] had zero validation or observability when a combo name collided with a real model id, and sseModelService.getComboForModel() always resolves the combo first. That combo-first precedence is not a bug: #6940 documents a combo named after a bare model id (e.g. `gpt-5.5`) as the supported mechanism for per-model provider fallback, reusing the #3227/#3233 machinery and covered by tests/unit/responses-combo-resolution-3227.test.ts and tests/unit/combo-name-codex-responses-rewrite.test.ts. Hard-rejecting a colliding name (as #8530's literal acceptance criteria requested) would regress that documented workflow. Instead, both routes now attach a non-blocking `warning` field (`COMBO_NAME_SHADOWS_MODEL`) to the create/rename response when the name collides with a real model id, and a new boot-time scan (scanComboModelNameCollisionsAtBoot in src/instrumentation-node.ts) logs a startup warning enumerating existing collisions — so an operator who hits this by accident has a signal, while the #6940-sanctioned pattern keeps working exactly as before. New tests/unit/combo-model-name-collision-8530.test.ts proves both: the sanctioned shapes (create/rename to a colliding name) still return 201/200 with the warning attached, and non-colliding names get no warning field at all.