mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-09-19 13:23:50 +03:00
d1b26bcb62
modelMetadataRegistry's findInsensitive() warned once per colliding key while building its lowercase index. On a real catalog that is hundreds of lines per rebuild: a production log carried 27,296 of these in a single file — 40% of all lines, in ~500/sec bursts — driving 52 MB log rotations and ~466 MB of logs on disk. The warning itself is worth keeping: a case-insensitive collision is a genuine upstream data-quality signal (models.dev returning both "OpenAI" and "openai" as distinct provider keys), and first-match-wins silently discards the later value. Only the volume was wrong. Collisions are now collected during the index build and reported as a single line carrying the total count plus the first 5 keys, so the diagnostic survives at 1/N the volume. No behavior change: the index, the first-match-wins resolution, and the WeakMap identity cache are untouched. Validated by TDD (Hard Rule #18): tests/unit/model-metadata-registry-collision-log.test.ts fails on the old implementation (3 collisions -> 3 warnings, 50 -> 50) and passes after (always 1). Also covers the no-collision case emitting nothing, and asserts the aggregated line still names colliding keys. Note for reviewers: the test fixture deliberately spells the provider key "OpenAI" rather than "openai". findInsensitive short-circuits on `if (key in obj) return obj[key]` before the index is ever built, so a fixture containing the literal lookup key produces zero warnings and proves nothing. Gates: eslint clean on both changed files. typecheck:core reports 9 pre-existing errors in open-sse/services/compression/omniglyph* — unrelated to this change (those files are byte-identical to origin/release/v3.8.50) and caused by a local stale node_modules carrying omniglyph 1.3.1 against the required ^1.4.0. Co-authored-by: diegosouzapw <8016841+diegosouzapw@users.noreply.github.com>