mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-03 05:45:04 +03:00
6706d5ff7d
* fix(api): serve the model catalog stale-first and sanitize its error body A client with a short discovery timeout (Claude Code allows 3s) hit a full catalog rebuild — 290 providers plus SQLite reads — every time the memoized entry expired, and got an empty model picker with no error. Serve an expired entry immediately and revalidate in the background, bounded by a staleness window so a permanently failing refresh cannot pin an old catalog forever. Only a cached 200 is eligible; a state change still drops the cache outright. The builder's catch block also returned the raw error message in the response body. Route it through the shared sanitizer (hard rule #12). * fix(api): reject a failed catalog refresh instead of resolving it stale catalogInFlight is shared with the cold path, so resolving the background refresh with the stale entry handed it to callers that had already aged past CATALOG_STALE_WHILE_REVALIDATE_MS — a stale 200 they were no longer entitled to, with a build failure disguised as success. The refresh now rejects; the stale path never awaits it (the rejection is pre-handled, so it can never surface as an unhandledRejection) and a cold-path caller that joins it gets the sanitized 500. A failed refresh still leaves the cached entry untouched. Also sanitize the core builder's own catch — that is the realistically reachable 500 for this endpoint, and it still returned the raw error message (hard rule #12); keep the cache-key format private to the module by having the two test hooks take the Request and derive the key themselves. * refactor(api): extract the model-catalog response cache into its own module The stale-while-revalidate work pushed catalog.ts from 1615 to 1745 lines, past its frozen size cap. Raising the cap on a file already flagged as too large is the wrong answer: the caching layer is a self-contained concern (coalescing, TTL memoization, staleness window, background refresh) that only needs a builder callback from the catalog module. catalogCache.ts now owns the maps, the cache key, the state-change invalidation, the header merge, the background refresh and the test hooks; catalog.ts keeps auth, the builder, and the error shape, and re-exports the hooks so the existing tests keep importing them from where they always did. Net effect: catalog.ts 1745 -> 1513, i.e. 102 lines below the cap it was frozen at, and the test-only surface no longer sits in the production catalog module. No behavior change — all 281 tests across every suite importing catalog.ts pass, including the #6408 one-builder-run guard.